Authentication and Authorization

What we're doing: Show a request that passes authentication cleanly but must still be rejected by authorization.

1. POST /invoices/900/delete
   Authorization: Bearer <valid JWT for user_id=482>

2. Authentication step:
   - signature valid, not expired -> identity = user_id 482
   - this step succeeds; 482 is a real, logged-in user

3. Authorization step:
   - invoice_id 900 belongs to user_id 117, not 482
   - 482 has no admin role either
   - this step fails

4. Response: 403 Forbidden
   (NOT 401 -- the caller proved who they are just fine;
   they are simply not allowed to delete someone else's invoice)

2

Authentication succeeding only proves the JWT belongs to a real, currently-valid user_id 482 — it proves nothing yet about invoice 900.

8

This is the authorization check: same confirmed identity, a different question entirely — ownership of this specific resource.

12

The status code distinguishes the two failure modes for the client: 401 means "prove who you are again," 403 means "you already did, and the answer is still no."

Why this works: The request never fails to authenticate — the token is completely valid — which is exactly the case that exposes a system that conflates the two checks: code that stops at "token is valid" and treats that as permission would incorrectly let user 482 delete an invoice they do not own.

What we're doing: Trace what a compromised session cookie vs a compromised JWT lets an attacker do, and how each is stopped.

Scenario A: session cookie stolen (e.g. via a
fixed XSS bug before HttpOnly was added)
  1. Attacker sends stolen sid in a request.
  2. Security team deletes that session_id from
     the session store.
  3. Next request with that sid: server finds no
     matching session -> rejected immediately.

Scenario B: JWT stolen (e.g. leaked in a log line)
  1. Attacker sends stolen JWT in Authorization header.
  2. Signature is valid, exp has not passed yet ->
     server accepts it, because it never consults
     any server-side record.
  3. Security team cannot invalidate this one token
     without a denylist keyed by token ID (jti) --
     if none exists, the token stays valid until
     its exp timestamp, however long that is.

3

Deleting the server-side session record is the entire revocation mechanism for cookie-based auth — one delete, effective on the next lookup.

13

A JWT's statelessness is exactly what removes this lever — there is no server-side record to delete, only the token's own expiry.

16

A denylist (a small server-side store of revoked token IDs, checked on each request) reintroduces a lookup — trading back some statelessness for the ability to revoke early.

Why this works: The same event — a stolen credential — plays out differently depending purely on where identity lives: server-side state makes revocation immediate and centralized, while a self-contained signed token makes revocation either impossible before expiry or requires deliberately rebuilding the lookup that statelessness was meant to avoid.

What we're doing: Show why reading the access token instead of the id_token to identify a user is a real, exploitable mistake.

1. User completes "Sign in with Provider".
2. App backend exchanges the auth code for:
   - access_token: opaque string, scope=openid email
   - id_token: JWT with claims {sub, email, aud, exp}

3. App needs to know: which user just logged in?

WRONG: call the provider's /userinfo endpoint using
       the access_token and trust whatever comes back
       as if it were validated locally -- if /userinfo
       is ever called against the wrong provider config
       or over a misconfigured proxy, nothing locally
       verifies the response's signature or audience.

RIGHT: verify the id_token's signature against the
       provider's published public key, check aud
       matches this app's client_id, check exp has
       not passed, THEN read the 'sub' claim as the
       verified, stable user identifier.

3

access_token and id_token are handed back together but serve entirely different jobs — this is the exact point OAuth-vs-OIDC confusion happens.

10

Trusting an unverified network response as identity skips the one step (signature + audience verification) that actually makes an id_token trustworthy.

16

The id_token is a signed JWT specifically so the app can verify it locally without an extra network round trip — verifying it is what OIDC adds beyond plain OAuth.

Why this works: The access token proves the app may call certain APIs on the provider; only the signed, verified id_token proves who the user actually is — treating the two as interchangeable is the single most common way teams accidentally build authentication on a protocol (OAuth) that was never designed to provide it.

What we're doing: Compare how a leaked credential plays out under a static API key versus short-lived mTLS-issued identity.

Static API key leaked in a public repo commit:
  - valid immediately for whoever finds it
  - stays valid until someone notices and manually
    rotates it -- could be hours, could be months
  - full blast radius: every permission that key had

Short-lived mTLS/workload certificate leaked:
  - valid only until its (typically short) expiry
  - auto-rotation means the leaked cert becomes
    useless on its own within the rotation window,
    with no manual action required
  - blast radius is bounded by time even before
    anyone notices the leak

2

A static key has no built-in clock — its exposure window is however long it takes a human to notice, which is the core weakness of any long-lived shared secret.

10

Automatic short-lived rotation converts "someone must notice and act" into "the problem resolves itself within a bounded window" — a structural difference, not just a smaller number.

Why this works: The mechanism itself decides whether a credential leak is an incident that resolves on its own or one that depends entirely on a human noticing — this is the practical reason internal, high-scale service-to-service traffic increasingly moves toward short-lived, auto-rotated identity instead of static keys.

What we're doing: Show an RBAC check that passes correctly, followed by the missing object-level check that lets it access the wrong resource.

Request: PUT /posts/771/edit
Caller: user_id=482, roles=['editor']

Step 1 -- RBAC check:
  'editor' in user.roles -> True
  (this only proves 482 is SOME editor, not that
  they may edit post 771 specifically)

Step 2 -- fetch resource:
  post_771.author_id == 900   (belongs to a different user)

Step 3 -- object-level check (if present):
  post_771.author_id == user.id?  900 == 482?  False
  -> 403 Forbidden

If step 3 is skipped: the edit succeeds, because
step 1's role check was the only gate, and it was
satisfied by ANY editor regardless of which post
they targeted.

4

The role check answers "is this user an editor," a category question — it has no concept of post 771 specifically.

9

Only once the actual resource is fetched does its ownership become checkable at all.

13

This is the object-level authorization check — comparing the resource's own owner field against the caller, not just their role.

Why this works: RBAC and ABAC both operate on categories and policies; only a check that loads the specific resource and compares its ownership or grants against the caller closes the gap between "an editor may edit posts" and "this editor may edit this post" — omitting it is exactly what OWASP's API Security Top 10 calls Broken Object Level Authorization.