API Authentication & Authorization (OAuth2/JWT)

Authentication (AuthN) answers "who are you?" — proving identity from a credential. Authorization (AuthZ) answers "what may you do?" — deciding whether a known principal may perform this action on this resource. AuthN happens first; AuthZ runs on every protected operation after.

Missing or invalid credential → 401 Unauthorized (a historical misnomer; it really means unauthenticated). Known principal who isn't permitted → 403 Forbidden.

No. OAuth 2.0 is a delegated authorization framework: it lets a user grant an app scoped access to their resources without sharing a password. Treating an OAuth access token as proof of identity is a classic gotcha — the access token is for the resource server, not for identifying the user to the app.

API1: BOLA — Broken Object Level Authorization. The endpoint confirms you're authenticated (and maybe role-permitted) but never checks you own the specific object, so changing an id returns someone else's data. It's #1 because it's pervasive and high-impact.

It protects public clients (SPAs, mobile apps that can't keep a secret) against authorization-code interception. The client generates a random code_verifier, sends its hash (code_challenge) on the auth request, and must present the original verifier at token exchange. An intercepted code is useless without the verifier, binding the code to the requester.

aud names the intended recipient(s) of the token. A resource server must verify the token was issued for it — otherwise a token minted for service A could be replayed against service B (the "confused deputy"). Audience-checking is what stops one service's token from being a skeleton key for another.

It verifies the authenticated principal may act on this specific object, not merely that they're authenticated or role-permitted. It bites because RBAC/ABAC answer "can this kind of user do this kind of thing" but not "does this user own this record." Skipping it is OWASP API #1 — BOLA — the most common API breach.

Revocation. A self-contained token is valid until exp, no matter what — there's no row to delete. A server-side session is the opposite: trivial to revoke (delete it), but stateful (needs a shared store or sticky sessions). The design tension is pure statelessness vs instant logout.

alg: none: attacker sets the header algorithm to none and strips the signature; a naive verifier that trusts the header accepts an unsigned token. Algorithm confusion (RS256→HS256): the server expects an RSA-signed token (verify with the public key) but the attacker sends an HS256 token signed with that public key as the HMAC secret; a library that picks the algorithm from the header validates it. Defense: pin the expected algorithm(s) server-side and never let the token's header choose how it's verified.

mTLS authenticates the connection at the transport layer — strong, sender-bound, great inside a service mesh, but it tells you which service connected, not on whose behalf. Signed JWTs carry application-level claims (caller, scopes, end-user context, audience) and survive proxy hops, but are bearer by default (replayable if leaked). Mature systems combine them: mTLS for channel identity + a JWT for fine-grained, propagated authZ context.

Externalize policy: a centralized decision model (e.g. a policy engine / OPA-style PDP, or a relationship-based system à la Google Zanzibar for object-level checks) with services as enforcement points. Propagate identity and scopes via signed tokens, version policies, and test them. The anti-pattern is ad-hoc if checks copy-pasted per service — they drift, and one missed check is a BOLA.

A strong answer covers: separate the actors first — interactive users vs machine-to-machine partners have different grants → standardize on OAuth2: end users via Authorization Code + PKCE with OIDC for identity (an id_token with sub/email), partner backends via Client Credentials or mTLS with no user in the loop → issue short-lived signed JWT access tokens + rotating refresh tokens; sign with RS256/ES256 and publish a JWKS so every resource server validates locally without holding signing power — preserving REST statelessness → on every request, validate signature, pin the algorithm (reject alg: none/confusion), and check iss, aud (audience is you, to stop confused-deputy replay), and exp/nbf → authorization in layers: scopes for coarse "what the token may do," role/attribute checks, and critically the per-object tenant/owner check derived from the token (WHERE id=:id AND tenant_id=:tokenTenant) enforced in a shared data layer so no endpoint can forget — this is what shuts down BOLA, the #1 OWASP API risk → revocation: short expiry for the common case + a denylist/introspection for emergency logout, family revocation on refresh-token reuse, JWKS kid rotation if a key leaks → hygiene: TLS everywhere including internal hops, tokens only in headers, secrets rotated, no PII in the JWT → name the trade-off: stateless JWTs scale out but make instant revocation hard, which the short-expiry + denylist combo resolves at the cost of a little state.

A strong answer covers: start from the threat model — APIs expose object ids directly and are hit programmatically, so authorization (not injection) is the dominant breach class → authenticate with bearer tokens over TLS, but treat authentication as table stakes; the work is authorization → defend API1 BOLA with a per-object owner/tenant check on every access, derived from the token, in a shared data-access layer; make clear that unguessable UUIDs are obscurity, not a control → defend API3 BOPLA with explicit allow-lists for readable and writable fields — never bind request bodies straight onto the model (mass assignment like "isAdmin":true) and never over-return (passwordHash, others' PII) → defend API5 BFLA by denying by default and enforcing role/permission per function including non-GET methods, so a user can't reach admin routes by guessing a path or swapping a verb → defend API4 Unrestricted Resource Consumption with rate limiting (429 + Retry-After), pagination caps, payload-size/timeout/query-complexity limits, and per-principal quotas (also stops financial DoS) → defend API2 Broken Authentication with strict token validation (pin alg, check iss/aud/exp), login rate limiting + MFA, short token lifetimes → if the API fetches user-supplied URLs, defend API7 SSRF by allow-listing destinations, blocking private/link-local ranges, and resolve-then-validate against DNS rebinding → cross-cutting: return safe errors (no stack traces / SQL), audit-log authorization decisions, and add automated cross-tenant / privilege-escalation tests → name the trade-off: centralizing policy (a PDP / Zanzibar-style relationship model) keeps checks consistent across services but adds a dependency vs fast-but-drift-prone per-service if checks.