Authentication & Authorization (RBAC)

API Now! includes a built-in security engine to manage who can sign in and what operations they are authorized to perform. You configure these strategies in the API Modeler’s Security panel.

Authentication Strategy

Authentication determines how a user proves their identity to the API:

UsernamePassword Strategy

The primary authentication strategy is UsernamePassword. It enables standard credentials-based login.

Validation Requirements

If you select the UsernamePassword strategy, the API validator enforces that:

The designated User Entity in your Data Domain must contain a property annotated with the Username semantic module.
If missing, the model validation will fail with an error, prompting you to configure a username lookup field (typically an email address or username string).

Future Authentication Strategies

For now, API Now! focuses on the UsernamePassword strategy as it is the most common credentials-based access method. In the future, we plan to add support for more authentication strategies, including:

OAuth2 / Social Sign-In (Google, GitHub, etc.)
Single Sign-On (SSO) / SAML
API Keys for machine-to-machine integrations

We are always looking for feedback to shape our roadmap. If you have specific authentication use cases or systems you want to connect, please let us know so we can design and build strategies that benefit your applications!

Authorization Strategy (RBAC)

Authorization determines what actions an authenticated user is permitted to perform based on their role:

Role-Based Access Control (RBAC)

The core authorization strategy is Role-Based Access Control (RBAC). In this strategy, you group permissions into roles (e.g., Admin, Editor, Viewer) and assign a single role to each user.

Validation Requirements

When using the RBAC strategy:

The User Entity must contain a property annotated with the UserRole semantic module.
The allowed roles are derived dynamically from the property’s base enum list (e.g. ['admin', 'viewer']).
The Session Configuration must map the role property key into the session payload so the authorization engine can evaluate permissions on each request.

Access Denied (403)

If a user tries to access an endpoint protected by a role check (such as HasRoleAccessRule) and their role is not authorized, the server will reject the request with a 403 Authorization Denied error.

For details on the forbidden payload, refer to the Authorization Denied Error Guide.