Authorization Models
Ownership checks, roles, permissions, attribute policies, scopes and tenant isolation are different tools for the same question — and most real systems need three of them at once, layered in a specific order.
Frame the problem
Security starts with a concrete asset, attacker capability and trust crossing.
The models, and the question each answers
Authorization is not one mechanism. Ownership asks whether the requester created or is assigned to this record. Roles (RBAC) ask which coarse job the requester holds. Permissions ask which specific verbs on which resource types. Attributes and policies (ABAC) evaluate a rule over requester, resource and context. Scopes bound what a delegated token may do, independent of what the user could. Tenancy partitions everything by organisation before any other question is asked.
Most production systems layer them: tenant isolation first (a query that cannot cross tenants), then ownership or role, then a scope check when the request arrives via a delegated token. Treating any single model as complete is how the gaps appear — RBAC without ownership lets any member read every member's record; ownership without tenancy leaks across organisations when an id is guessed.
| Model | Question | Good for | Fails when |
|---|---|---|---|
| Ownership | Is this mine? | User-owned records: invoices, messages, uploads | Sharing and delegation are needed |
| RBAC | What is my job? | Small, stable sets of job functions | Roles multiply per feature — role explosion |
| Permissions | May I do verb X on type Y? | Fine-grained admin tools, API tokens | Per-record decisions (which invoice?) |
| ABAC / policy | Does the rule allow it? | Context-dependent rules: region, time, classification | Rules become unauditable |
| Scopes | What may this token do? | Delegated and machine access | Treated as user permissions |
| Tenancy | Which organisation? | Every multi-tenant system | Enforced in some queries, not all |
Layering in order
The order is determined by blast radius. Tenant isolation is checked first because a failure there exposes another customer. Coarse role checks come next because they are cheap and stop most wrong requests before a resource is loaded. Ownership and policy are last because they need the loaded record. Scopes apply as an additional ceiling whenever the principal arrived via a delegated token: the effective permission is the intersection of what the user may do and what the token was granted.
This layering makes a useful test: for any endpoint, name the tenant check, the role check, the record check and the scope ceiling. An endpoint that can name only one is usually the one with the bug.
Key points
- Authorization is several models layered, not one mechanism chosen.
- Order by blast radius: tenant → role → resource ownership/policy → scope ceiling.
- Delegated tokens intersect, never extend, the user's permissions.
- For any endpoint, name all four checks; the one you cannot name is the finding.
Boundary control exercise
This lesson uses the shared boundary-control exercise.
Follow the attack
Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.
- 1Attacker → authenticated account or scoped token.
- 2Find the endpoint where one layer is missing — usually record-level ownership.
- 3Substitute an id; the surviving layers all pass because the request is otherwise legitimate.
- Cross-user or cross-tenant data exposure with fully authenticated, unremarkable traffic.
Defend, detect, recover
One prevention is a single point of security failure. Layer it and make failure observable.
- • Enforce tenancy in the data layer so it cannot be skipped.
- • Check ownership against the loaded record.
- • Apply scopes as a ceiling on delegated requests.
- • Write the four-layer test per resource type.
- • Log requester and resource owner; alert on mismatches without a sharing relation.
- • Alert on tokens exercising scopes they were not granted.
- • Scope disclosure from access logs; fix the endpoint and every sibling with the same shape.
- • Sharing and delegation rules are where correctness gets subtle.
- • Admin and support tooling bypass ownership by design.