Authorization

Authorization determines what an authenticated user is allowed to do. While authentication answers the question of who you are, authorization answers what you can access and which actions you can perform. A secure API must get both right.

Authorization models range from simple role-based checks to fine-grained attribute and policy engines. The right model depends on the complexity of your domain, the size of your user base, and compliance requirements.

This guide covers role-based access control, attribute-based access control, claims, permission models, ownership checks, and practical patterns for enforcing authorization in HTTP APIs.

Role-based access control, or RBAC, assigns permissions to roles and roles to users. It is the simplest authorization model and works well when your access rules align with job functions. For example, an admin can manage users, an editor can publish content, and a viewer can only read.

RBAC is easy to understand and audit. The main risk is role explosion: as requirements become more granular, teams create ever more specific roles. When that happens, it is time to add permissions or attributes.

Attribute-based access control, or ABAC, evaluates policies against attributes of the user, the resource, the action, and the environment. It is more expressive than RBAC and supports rules such as managers can approve expenses up to their department limit during business hours.

ABAC is powerful but harder to reason about. Policies can interact in subtle ways, and debugging access decisions becomes more complex. Start with RBAC and introduce ABAC when role-based rules are no longer sufficient.

Claims are statements about a user carried by an identity token. Common claims include user ID, email, roles, and groups. When the token is signed, services can trust these claims without calling an identity provider on every request.

Keep claims small and stable. Tokens have size limits and are hard to revoke. Avoid putting rapidly changing permissions directly in a JWT. Instead, put stable identity claims in the token and look up permissions from a store or cache when needed.

Many authorization decisions reduce to ownership. A user should be able to update their own profile but not someone else's. A team member should be able to edit team resources. Ownership checks happen after authentication and before business logic.

Load the resource before checking ownership. Do not rely on the resource ID in the URL alone. A malicious user could pass a valid ID they do not own. Fetch the resource, compare the owner, and fail fast with a 403 status if the check fails.

For complex authorization, a dedicated policy engine separates access rules from application code. Open Policy Agent uses the Rego language to express policies. Cedar, developed by AWS, is optimized for authorization at scale. These engines accept a query and return allow or deny decisions.

Permissions can be structured in several ways. Coarse-grained permissions such as post:write are simple but inflexible. Fine-grained permissions such as post:edit:published or resource-level ACLs are more powerful but harder to manage.

Enforce authorization as close to the operation as possible. Middleware is good for coarse checks such as requiring an admin role. Ownership and data-level checks usually belong in the service layer because they require loading the resource.

Never rely on client-side checks. A motivated user can bypass any UI restriction. All authorization decisions must be made on the server, using data the client cannot manipulate.