Security
Part 1 of 6 · AuthorizationAuthorization — RBAC, ABAC, ReBAC & Policy Engines
Hub decision tree for AuthZ models and PEP/PDP placement; AuthN left to OAuth & OIDC cluster.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
When a valid identity is still not an allow
Prefer
AuthZ context after AuthN
The subject is already named. The decision still needs action, resource, and environment, then a default deny.
- A proven principal is a noun. Authorization is a verb over a resource.
- Roles, attributes, or relationship tuples supply the evidence.
- Every trust boundary re-checks. The edge is not the whole story.
Alternative
A valid credential treated as permission
The caller is authenticated, so the handler returns the row. Resource ownership, tenant, and revoke never enter the decision.
- Coarse role strings copied into every service drift apart.
- Cached allows outlive a revoke.
- A direct database path skips the API check entirely.
AuthN, then AuthZ
Identity is an input. The allow is a separate decision.
- 1
Request arrives
A credential or session is present. That only starts authentication. - 2
Subject is established
AuthN yields a stable subject id. How that proof was issued lives in the OAuth and OIDC cluster. - 3
Build AuthZ context
Subject, action, resource, and environment. Missing fields are not an allow. - 4
PEP asks the PDP
The enforcement point does not invent policy. The decision point evaluates roles, attributes, tuples, or a policy bundle. - 5
Allow or fail closed
Allow may still filter rows and apply obligations. Deny, timeout, or incomplete context returns 403 or an empty safe set, then both paths are audited.
Overview
Authentication answers who is calling. Authorization answers what they may do to which resources under which conditions. Senior interviews fail when those questions collapse into "we check the token" or "we just check roles." Production fails when the enforcement point and the decision point disagree, when a cached allow outlives a revoke, or when the data layer returns rows the API already denied.
This cluster is the AuthZ decision tree: RBAC, ABAC, ReBAC, policy engines, and where enforcement lives. It assumes the caller is already identified.
You should be able to:
- Draw subject, action, resource, and environment before you name a product.
- Say which model you start with, and the symptom that forces the next one.
- Name the layer that still checks if the gateway is bypassed.
Identity stays in OAuth & OIDC
AuthN is a different series. Link these lessons by title when the question is who the caller is, how a token was issued, or how a session is stored. Do not re-teach them here.
- OAuth 2.1 & OIDC — Authorization Code + PKCE
- OpenID Connect — ID Tokens, UserInfo, Discovery & Nonce
- JWT vs Opaque Tokens — Validation, JWKS & Revocation
- BFF Cookie Sessions vs SPA Bearer Tokens
- Refresh Token Rotation & Reuse Detection
- Service-to-Service Auth — mTLS, Client Credentials & Workload Identity
- OAuth Threat Model — CSRF, Token Leakage, Confused Deputy & Common Pitfalls
OAuth scopes are a coarse signal from the authorization server, often "this client may call this API." Application AuthZ still checks the resource. scope containing read is not "read any row."
Map of the cluster
| Part | Lesson | Focus |
|---|---|---|
| 1 | This hub | Decision tree and enforcement map |
| 2 | RBAC | Subject, role, permission, and separation of duties |
| 3 | ABAC | Attributes, PDP, PEP, obligations |
| 4 | ReBAC and Zanzibar | Tuples, check vs list, consistency tokens |
| 5 | Policy engines | OPA/Rego, Cedar, custom code |
| 6 | Enforcement | Gateway, service, data filters, fail closed |
Decision tree
Flow
- 1
1. Request arrives
- next2. AuthN names subject
- 2
2. AuthN names subject
- next3. Build AuthZ context
- 3
3. Build AuthZ context
- next4. PEP asks PDP
- 4
4. PEP asks PDP
- next5. Allow and filter
- next5. Deny, fail closed
- 5
5. Allow and filter
- next6. Audit the decision
- 6
5. Deny, fail closed
- next6. Audit the decision
- 7
6. Audit the decision
Lesson map
Authorization — RBAC, ABAC, ReBAC & Policy Engines
Hub decision tree for AuthZ models and PEP/PDP placement; AuthN left to OAuth & OIDC cluster.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["1. Request arrives"] b["2. AuthN names subject"] c["3. Build AuthZ context"] d["4. PEP asks PDP"] a -->|1. Request arrives| b b -->|2. AuthN names subject| c c -->|3. Build AuthZ context| d
Use the shape of the permission, not the product you already run:
- Mostly job titles and a handful of personas? Start with RBAC.
- Same role, different conditions (region, time, clearance, risk)? Prefer ABAC and a policy engine.
- Access follows ownership, folders, groups, or sharing? Prefer ReBAC.
- Role explosion, separation-of-duties pain, or "own documents only"? Hybrid: a coarse role gate, then attributes or relationships for depth.
- Whatever you pick, enforce at every trust boundary and fail closed.
Rule of thumb: start RBAC for coarse gates. Add ABAC when the sentence is "same role, different conditions." Add ReBAC when permission is a path: a user is an editor of a folder that contains a document.
Model choice
| Model | Pros | Cons | Use when |
|---|---|---|---|
| RBAC | Auditable "who has role X"; easy mental model | Role explosion; weak on "own docs only" | Small org; admin, editor, viewer; stable job functions |
| ABAC | Fine-grained; time, IP, risk in one policy | Attribute quality and policy bugs | Regulated or dynamic conditions; multi-tenant attributes |
| ReBAC | Natural shares, folders, and org graphs | Consistency tokens; list vs check | Collaboration and inherited access |
| Hybrid | Roles for entry, attributes or relations for depth | More moving parts; clear ownership of each layer | Most products that outgrow a role dropdown |
Where PEP and PDP live
| Layer | Role | Typical home |
|---|---|---|
| API gateway | Coarse PEP: authenticated, role allowlist, geo | Envoy external auth, Kong, API gateway authorizers |
| Service middleware | Fine PEP: action plus this resource | Library call into OPA, Cedar, or a tuple check |
| Policy decision point | Evaluate policy or walk tuples | OPA, Cedar, SpiceDB, or a custom evaluator |
| Data layer | Last-mile filter | Postgres row security, ORM predicates |
The gateway is not enough. A worker, a mesh-internal call, or a SQL console bypasses the edge. Defense in depth means every trust boundary asks again. Depth is the enforcement lesson.
Sandbox: identity proven is not permission granted
Educational RBAC after a stub AuthN. Delete is owner-only. Update allows the editor role. Anything else denies.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Expect allow for Alice writing her own document, and a deny if you change ownerId to someone else. The editor role is not a write on every document.
Interview Q&A
AuthN vs AuthZ in one sentence each?
Answer
AuthN proves identity (who). AuthZ decides permitted actions on resources under conditions (what). A valid token is not an allow. Identity issuance stays in the OAuth and OIDC cluster.
When does RBAC break?
Answer
Role explosion (a role per tenant or per resource), "own resource only" rules, and environment conditions such as time, device, or risk that a role name cannot express cleanly. Those are the exits to ABAC or ReBAC.
What are PEP and PDP?
Answer
The policy enforcement point intercepts the request and applies the answer. The policy decision point evaluates policy or tuples and returns allow or deny, sometimes with obligations. Keep them separable so many PEPs share one decision logic and one test suite.
Why not only authorize at the API gateway?
Answer
Services get called internally. Workers and database access bypass the edge. Enforce at every trust boundary, and use data filters or row security as the last line.
RBAC vs ABAC vs ReBAC for Drive-style sharing?
Answer
ReBAC. Folders, editors, viewers, and inherited access are graph edges, not a flat role per document. ABAC can express a single owner id. It gets awkward on multi-hop shares.
What is fail-closed?
Answer
If the PDP is down, a sensitive cache misses, or context is incomplete, deny or degrade to a safe subset. Do not open the door. Pair that with break-glass that is audited and time-boxed. The enforcement lesson is the runbook.
How do OAuth scopes relate to this cluster?
Answer
Scopes are a coarse capability the authorization server granted the client. They are not a resource check. read on the token does not mean read any row. Application AuthZ still runs.
What does a hybrid actually look like?
Answer
A persona role gets you into the product (support, billing admin). Attributes or relationship tuples decide the instance: this tenant, this folder, this hour, this risk score. Each layer has an owner. You do not encode the tenant id into the role name.
What do you audit besides allow or deny?
Answer
Who the subject was, the action, the resource id, the policy or tuple version, the attributes that mattered, and the latency. You also audit who granted the role or wrote the tuple. Decision logs stay free of raw credentials.
Pitfalls
Draw subject, action, resource, environment. Under the resource box, write one sentence that is a role, one that is an attribute condition, and one that is a share path. Circle the model you would ship first, and name the sibling lesson that owns the depth.