Authorization determines what an authenticated identity (user, application, or service) can do and which resources it can access within a system.

In most systems, authorization follows authentication (AuthN). Once the system knows who you are, authorization determines what you’re allowed to do.

Authorization ensures that every authenticated identity operates within defined boundaries. Without it, a user who logs in successfully (AuthN) could access all sensitive data and perform any action (AuthZ failure). In Zero Trust architectures, authorization decisions are continuously evaluated throughout a session, not only at initial access.

Authorization connects three main components:

• Users (authenticated identities)
• Permissions (specific rights to perform actions, like read:Patients)
• Resources (the assets being protected)

RBAC is the foundational authorization model. It simplifies permission management by assigning permissions to roles (e.g., Admin, Editor, Viewer) and then assigning those roles to users.

• How it Works: The system checks the user’s assigned role(s) and aggregates their permissions to determine if the requested action is allowed.
• When to Use It: When user permissions align clearly with static job functions or groups (e.g., in a typical enterprise or administrative application).
• Limitation: RBAC is less suited for dynamic or contextual policies, like those based on device, time, or location, because roles are typically static.

Enterprise IAM systems and large-scale cloud environments implement RBAC through their frameworks.

ABAC uses dynamic policies that evaluate attributes of the user, the resource, and the environment to make an access decision.

• How it Works: Access is determined by policy expressions that evaluate in real time (e.g., user.department == resource.department, or checking if the current time falls within business hours).
• When to Use It: When authorization decisions are complex, highly contextual, or dependent on dynamic factors (e.g., granting access only from a corporate IP range, allowing document access only during business hours, or requiring specific security clearance levels for sensitive resources).
• Tradeoff: It introduces complexity. Policies must be carefully designed and thoroughly tested to prevent conflicts or unintended access across various attribute combinations.

Standards-based policy engines (such as Open Policy Agent or XACML) enforce ABAC policies to maintain consistency and auditability.

ReBAC bases authorization on the relationships and ownership between a user and a specific resource.

• How it Works: The system checks for explicit relationships (e.g., “owner of,” “shared with,” “member of group”) to grant or deny access. Current implementations use graph-based relationship modeling to navigate complex permission chains.
• When to Use It: In collaborative systems like social media or document sharing platforms (e.g., “only the post owner can delete it,” “users in shared workspaces can view all documents”).

ReBAC and FGA systems leverage relationship-aware infrastructure and graph-based authorization patterns to model and query these relationships at scale. Several open-source implementations (such as OpenFGA and SpiceDB) make this technology accessible to all developers.

Fine-Grained Authorization (FGA) extends ReBAC principles to enable authorization decisions based on complex relationship graphs at scale. FGA systems can answer questions like “Can user X edit document Y?” by traversing relationships through groups, organizations, and nested permissions. This model powers authorization in document collaboration and social platforms, where access can be inherited through folder hierarchies, group memberships, and sharing relationships.

API-driven applications enforce authorization via access tokens issued through the OAuth 2.0 authorization flow.

1. Authorization Mapping: After successful authentication, the Authorization Server determines the user’s granted permissions based on the chosen AuthZ model and any dynamic policies that apply (e.g., RBAC, ABAC).
2. Token Issuance: The server issues an access token, most commonly a JSON Web Token (JWT) that contains claims about the subject and their authorized scopes. Or it issues an opaque token that requires validation through the authorization server’s introspection endpoint. The authentication flow determines how tokens are acquired and which claims they contain.
3. API Enforcement: When an API receives a request, it validates the JWT and enforces the authorization rules based on the claims inside the token.

This token-based approach is stateless. The token contains everything the API needs: authorization context and a cryptographic signature.

Scopes define the permissions a client application requests from the Authorization Server. The Authorization Server grants only the scopes to which the user has authorized consent, and includes them in the issued Access Token.

• When an application requests an access token, it specifies the scopes it needs (e.g., read:documents, write:documents).
• The Authorization Server compares the requested scopes against the user’s actual permissions and grants only what the user can authorize.
• The issued access token contains the approved scopes. The API validates that the token contains the required scopes for the requested operation; if the token lacks the needed scope, the API denies access.

Roles typically define broad access sets, while scopes represent fine-grained, action-level permissions. Combining roles and scopes provides flexibility for APIs.

OpenID Connect (OIDC) extends OAuth 2.0 by enabling the issuance of ID tokens for user identity verification and profile claims, in addition to authorization scopes.

Every protected API endpoint must validate the incoming access token. Verify the token’s signature (helps ensure integrity and authenticity), expiration (exp claim), audience (aud claim), issuer (iss claim), and required permissions (scopes or roles). Additional validation may include checking the token revocation status, validating the nbf (Not Before) claim, and enforcing rate limits per client. For JWTs, authorization servers publish public keys via the JSON Web Key Set (JWKS) endpoint for signature verification.

APIs must return specific HTTP status codes to communicate the type of failure.

• 401 Unauthorized: This means Authentication failed or is absent. The request lacks valid credentials (the token is missing, invalid, or expired).

Examples: Missing Authorization header, expired JWT, invalid signature.

• 403 Forbidden: This means Authorization failed. The user’s identity is known (authenticated), but their permissions deny access to the requested resource or action.

Examples: A valid token, but the user lacks the admin role for DELETE /users/:id, resulting in an insufficient scope for the requested operation.

When authorization logic is scattered throughout the code, some paths may fail to enforce required checks, leaving vulnerabilities that attackers can exploit. Centralizing authorization enforcement through middleware or a policy engine is the best practice. Emerging approaches include Policy-as-Code, which utilizes languages like Rego (Open Policy Agent), separating authorization logic from application code and enabling centralized testing and auditing.

Step-up authentication balances security and usability. It challenges an already-authenticated user for additional factors (such as a biometric scan) only when they attempt a high-risk operation, such as a wire transfer or payroll modification. This approach is also called adaptive or contextual authentication.

Broken Object-Level Authorization (BOLA), also known as Insecure Direct Object Reference (IDOR), is a common vulnerability. It occurs when an API checks for general permission (e.g., “can read a document”) but fails to verify the user has access to the specific resource ID requested (e.g., “document ID 12345”). This vulnerability consistently ranks as API1:2023 in the OWASP API Security Top 10. Always validate both the action permission and the resource-level access.

Authorization is a component of access control. Access control is the broader security discipline encompassing authentication (verifying identity), authorization (granting permissions), and enforcement (ensuring policies are applied). Authorization refers explicitly to the decision-making and enforcement of what an authenticated identity can do.

Distributed systems enforce authorization at multiple layers: API gateway (coarse-grained), service mesh (network-level), or individual services (fine-grained). Token-based authorization using JWTs enables stateless verification across services. However, maintaining consistency is challenging. Policy updates must reach all services, and relationship-based decisions require centralized policy engines or distributed caching.

Authorization is one component of a comprehensive identity and access management strategy. Modern authorization frameworks, such as OAuth 2.0 and OpenID Connect, along with fine-grained models like ABAC, ReBAC, and Fine-Grained Authorization (FGA), enable developers to build more secure and scalable apps that align with Zero Trust principles. For more on authentication, access control models, and security best practices, explore Auth0’s Intro to IAM series.

Learn more