Ask the complete authorization question
Represent the subject, action, resource, tenant, and context explicitly. Use business-relevant actions such as invoice.approve or key.rotate rather than relying only on HTTP methods. Stable resource identifiers and types make policy easier to test and audit.
Determine where attributes originate and how fresh they must be. Token claims may carry stable identity facts, while ownership, account status, or resource state may require a trusted current lookup.
Combine models without role explosion
Roles work well for broad job functions; attributes can constrain context; relationships can express ownership, delegation, and group membership. Many mature systems combine these approaches rather than forcing every exception into a new role.
Keep default behavior restrictive. Unknown actions, resource types, or missing attributes should not silently inherit a broad permission. Return an indeterminate result when the system cannot make a trustworthy decision and enforce it safely.
Enforce close to the operation
Gateways can verify identity and route-level scopes, but object and workflow rules belong close to the data and business action. Inventory direct service calls, message consumers, batch routes, GraphQL resolvers, and administrative tools so they cannot bypass the same authorization model.
Cache only when the key includes every input that can change the result. Positive and negative decisions have different staleness risks, and high-impact revocation may need event-driven invalidation.
Test policy as executable behavior
Build matrices covering tenants, roles, relationships, object states, authentication strength, and expected denials. Add invariants such as no cross-tenant reads and no privileged writes by a disabled principal.
Test enforcement as well as decision output. A correct policy result offers no protection if an application ignores it, applies it after the sensitive action, or omits an obligation such as field masking.
Implementation checklist
- Model subject, action, resource, tenant, and context.
- Use business actions and stable resource types.
- Return allow, deny, or indeterminate with policy version.
- Enforce object rules close to the protected operation.
- Bind caches to complete inputs and plan revocation.
- Test expected denials and cross-tenant invariants.
Frequently asked questions
What is the difference between authentication and authorization?
Authentication establishes who or what is calling. Authorization decides whether that principal may perform a specific action on a specific resource under current conditions.
Can a gateway handle all authorization?
It can enforce coarse route or scope policy, but it often lacks current object ownership, tenant relationship, or workflow state. Application or data-layer enforcement is usually still required.
Should authorization failures return details?
Return a stable public error without exposing sensitive policy or object existence. Preserve richer reason codes and a decision identifier in protected internal logs.
