Supported Authorization Strategies

API Now! provides structured, out-of-the-box authorization strategies tailored to different business models and architecture patterns.

When creating an API Model, you select an Authorization Strategy in the Security settings. The chosen strategy determines how user identity and permissions are structured in your Data Domain, and configures the palette of available Access Rules.

1. Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is the standard security model for single-tenant applications, B2C apps, and straightforward internal tools.

In this model, permissions are tied directly to the User: each user is assigned a global role (such as admin, editor, or viewer) that dictates what operations they can perform across the entire application.

graph LR
    User["User (Account)"] -->|has global role| Role["User Role (e.g. 'admin', 'viewer')"]
    Role -->|grants access to| API["API Endpoints & Actions"]

When to Use

You are building a consumer app (B2C) or a standard business app where users do not belong to isolated tenant organizations.
User permissions are global and apply across all data (e.g., an admin can manage everything, a customer can only see their own orders).

Data Semantic Prerequisites

To use the RBAC strategy, your Data Domain must configure:

User: A designated User Entity.
UserRole: An enum property on the User entity defining the allowed roles (e.g., ['admin', 'editor', 'viewer']).
Session Configuration: The role property must be mapped in your API Model’s Session Configuration so the runtime engine can verify roles on every incoming request.

2. Organization RBAC

Organization RBAC is designed specifically for Multi-Tenant B2B applications (such as SaaS platforms, team workspaces, or client portals).

In a multi-tenant platform, a user’s permissions depend on which organization they are actively working in. A user might be an owner in their own company’s workspace, but only a viewer or guest in a client’s workspace. There is no single global role on the user; roles exist strictly within the context of an Organization Membership.

graph TD
    User["User"] -->|Member of| Membership["Organization Membership"]
    Org["Organization (Tenant)"] -->|Contains| Membership
    Membership -->|has contextual role| OrgRole["Org Role (e.g. 'owner', 'member', 'guest')"]
    OrgRole -->|grants access within| TenantData["Organization's Data"]

When to Use

You are building a multi-tenant SaaS application where customers have their own isolated team workspaces or accounts.
Access to resources (such as projects, documents, or billing settings) must be scoped to members of that specific organization.
Users can belong to multiple organizations with different roles in each.

Data Semantic Prerequisites

To use the OrganizationRBAC strategy, your Data Domain must configure:

Organization: An entity representing the tenant organization.
OrganizationMembers: A pivot association connecting Organization to User.
OrganizationRole: A property on the membership pivot association defining tenant-level roles (e.g., ['owner', 'admin', 'member']).

3. Enterprise RBAC

Enterprise RBAC combines both global system roles and contextual tenant roles into a unified hybrid authorization model.

In an enterprise platform, you often have Internal Staff (such as Customer Support, Platform Administrators, or Compliance Officers) who require global administrative privileges across all tenant data, alongside Tenant Members whose access is restricted to their specific organization.

graph TD
    subgraph "Global System Level"
        User["User"] -->|has global role| GlobalRole["Global Role (e.g. 'super_admin', 'support_agent')"]
    end
    subgraph "Tenant Level"
        User -->|Member of| OrgMember["Organization Membership"]
        OrgMember -->|has tenant role| OrgRole["Org Role (e.g. 'billing_admin', 'member')"]
    end
    GlobalRole --> API["API Security Scenarios"]
    OrgRole --> API

When to Use

You are building large-scale B2B SaaS or enterprise software requiring tiered administrative access.
You need system-wide administrative overrides (e.g., Support Engineers managing tickets across all tenants) while standard customers operate within isolated organization boundaries.

Data Semantic Prerequisites

Enterprise RBAC requires both sets of semantics in your Data Domain:

Global User Role: User entity with a UserRole semantic property.
Organization Multi-Tenancy: Organization entity, OrganizationMembers association, and an OrganizationRole property on the membership pivot.

4. Permission-Based Authorization (PBAC)

While RBAC models assign permissions based on named roles (e.g. editor), PBAC (Permission-Based Access Control) allows you to evaluate granular capability permissions (e.g., articles:publish, invoices:export, users:invite).

This provides maximum flexibility for applications with highly customized enterprise permission matrices. We are actively shaping this feature—if you have specific permission requirements, please share your feedback with our team!

5. Strategy Comparison Matrix

The following table summarizes the differences between each authorization strategy:

Authorization Strategy	Primary Target Use Case	Required Data Semantics	Key Role Rules
`RBAC`	Consumer apps (B2C), simple internal tools, single-tenant apps	`User`, `UserRole`	`Match User Role`
`OrganizationRBAC`	Multi-tenant B2B SaaS, team workspaces, client portals	`Organization`, `OrganizationMembers`, `OrganizationRole`	`Match Organization Role`
`EnterpriseRBAC`	Enterprise SaaS with internal platform staff and multi-tenant customers	`User`, `UserRole`, `Organization`, `OrganizationMembers`, `OrganizationRole`	`Match User Role` + `Match Organization Role`
`PBAC` (Roadmap)	Fine-grained capability-based permissions	Policy-defined	Future capability-based rules

6. Access Rules Availability Palette

All authorization strategies share a set of Baseline Access Rules for verifying authentication, ownership, attributes, and lifecycle state. In addition, strategy-specific rules become available based on your selected model.

Rules Supported by Strategy

Access Rule	Description	`RBAC`	`OrganizationRBAC`	`EnterpriseRBAC`
Allow Public (`allowPublic`)	Permits anonymous, unauthenticated callers	✅	✅	✅
Allow Authenticated (`allowAuthenticated`)	Requires a valid logged-in session	✅	✅	✅
Match Email Domain (`matchEmailDomain`)	Restricts access by user email domain	✅	✅	✅
Match User Property (`matchUserProperty`)	Matches a property in the user session	✅	✅	✅
Match Resource Owner (`matchResourceOwner`)	Restricts access to the creator / owner	✅	✅	✅
Relational Resource Owner (`relationalResourceOwner`)	Matches owner through related entity link	✅	✅	✅
Match Resource Attribute (`matchResourceAttribute`)	Checks record property (e.g. `published == true`)	✅	✅	✅
Lifecycle Status (`lifecycleStatus`)	Filters by entity lifecycle status	✅	✅	✅
Match Path Parameter (`matchPathParameter`)	Verifies route parameters against user session	✅	✅	✅
Match Project Role (`matchProjectRole`)	Checks membership role in a Project entity	✅	✅	✅
Match User Role (`matchUserRole`)	Checks global role on the user record	✅	❌	✅
Match Organization Role (`matchOrganizationRole`)	Checks role within tenant membership	❌	✅	✅

Rule Placement Hierarchy

Rules can be attached at different levels in the API Modeler:

Global API Model Level: Broad defaults applied across all endpoints (allowPublic, allowAuthenticated, matchUserRole, matchEmailDomain, matchUserProperty).
Exposed Entity & Action Levels: All baseline rules plus resource-specific and contextual rules (matchResourceOwner, relationalResourceOwner, matchOrganizationRole, matchProjectRole, lifecycleStatus, matchResourceAttribute, matchPathParameter).

Next Steps

Explore detailed configuration guides for each individual access rule:

Allow Public: Configure public endpoints.
Allow Authenticated: Protect endpoints with standard login.
Match User Role: Configure RBAC role scenarios.
Match Organization Role: Secure multi-tenant organization workspaces.