Mental model#
Authentication establishes which principal is making a request. Authorization decides whether that principal may perform this action on this resource in this context. Identity data is an input to policy, not proof that every resource is accessible.
Mechanism and state flow#
- Authenticate at a defined trust boundary and obtain a validated principal and session context.
- Resolve the requested action and authoritative resource, including its tenant and ownership.
- Evaluate deny-by-default policy using current attributes and relationships.
- Enforce the decision at every server-side entry point and downstream data boundary, not only in navigation.
- Record a safe decision audit with policy version and reason while keeping credentials and sensitive attributes out of logs.
Concrete example#
A signed-in user requests another tenant's invoice
The session is valid, so authentication succeeds. Authorization loads the invoice's tenant from the authoritative record, compares membership and role, and denies access before returning any invoice fields.
Architecture consequence: Keep tenant/resource lookup inside the authorization boundary and test object-level access independently of UI visibility.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Role-based policy | Permissions align with a small stable set of job functions. | Roles become coarse or multiply when context matters. |
| Attribute or relationship policy | Ownership, tenant, resource state, or delegation changes access. | Policy evaluation and explainability become more complex. |
| Central policy decision | Many services need consistent policy logic. | Enforcement still belongs at each service and policy availability becomes critical. |
Failure diagnosis#
- Failure
- The API trusts a tenant ID supplied by the client after login.
- Impact
- An authenticated user can select another tenant and access its objects.
- Detection
- Negative authorization tests succeed when only the tenant or object identifier changes.
- Mitigation
- Derive tenant membership from trusted identity and load resource ownership server-side; deny by default.
- Trade-off
- Authoritative checks add data access and caching decisions to the request path.
Checklist exercise#
Work the scenario before revealing your answer
- For read, update, export, and delete, name the principal, action, resource, tenant, and context.
- Write a negative test for cross-user, cross-tenant, stale-role, and direct-object access.
- Mark where policy is decided, enforced, cached, audited, and invalidated.
Level calibration#
| Level | Useful evidence |
|---|---|
| SDE I–II | Separate identity validation from resource authorization and test denied paths. |
| Senior | Model tenant, ownership, delegated access, caching, revocation, and audit boundaries. |
| Staff | Define policy and enforcement contracts across services without creating one implicit superuser path. |
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What is authenticated, and what is separately authorized?
- Where does resource ownership come from?
- How are role changes and revoked access reflected in caches?
- How do background jobs carry a constrained service identity?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.