API Auth: Keys, JWT, OAuth, mTLS + RBAC/ABAC/ReBAC

Every API has to answer two questions on every request: who is calling (authentication, or authN) and what are they allowed to do (authorization, or authZ). Getting the first wrong lets strangers in; getting the second wrong lets legitimate callers reach data that isn't theirs — which, as the next module shows, is the single most common API vulnerability. This lesson covers the four authentication mechanisms you will see in practice (API keys, JWT, OAuth2/OIDC, mTLS) and the three authorization models that decide access (RBAC, ABAC, ReBAC). For each, the GRC lens is the same: which control requirement it satisfies, and what evidence proves to an auditor that it actually operates.

Authentication: proving who is calling

API keys

An API key is a long, random string the caller sends with each request (usually in a header like Authorization: Bearer <key> or X-API-Key). The server looks it up and identifies the caller. Keys are simple and good for server-to-server calls and identifying applications — but a key is a bearer credential: anyone who has the string can use it. There is no built-in expiry, no user identity, and no scoping unless you add it. A key leaked into a git commit or a log file is a standing breach until someone rotates it.

• Control it satisfies: authenticate machine clients; attribute API usage to a known consumer.
• Evidence: a key inventory (who holds which key, what it can do), creation/rotation/revocation logs, and proof keys are stored in a secrets manager — not in code.

JWT (JSON Web Token)

A JWT is a signed token that carries claims — facts about the caller (user id, roles, expiry) — inside the token itself. The server verifies the signature and trusts the claims without a database lookup, which makes JWTs fast and stateless. The cost of statelessness: a JWT is valid until it expires, so you cannot easily revoke one mid-life. That forces two rules auditors look for: short expiry (minutes, not days) plus a refresh-token flow, and signature verification with a vetted library — the classic JWT vulnerability is a server that accepts the token's own alg: none header and skips verification entirely.

• Control it satisfies: stateless, scalable authentication carrying identity and authorization claims.
• Evidence: token policy (expiry, signing algorithm, key rotation), and proof the verifier rejects unsigned/none tokens.

OAuth2 / OIDC

OAuth 2.0 is a delegation framework: it lets a user grant a third-party application scoped access to their data without handing over their password. OIDC (OpenID Connect) is a thin identity layer on top of OAuth2 that adds "who is the user" (the ID token). This is the pattern behind "Sign in with Google" and behind most first-party web/mobile apps talking to their own backend. The key idea is the access token is issued by an authorization server, is short-lived, and is scoped — it grants read:invoices, not "everything."

• Control it satisfies: delegated, scoped, revocable access for users and third-party apps without password sharing.
• Evidence: the scope catalog (which scopes exist and what they grant), token lifetimes, consent records, and authorization-server logs of token issuance.

mTLS (mutual TLS)

Ordinary TLS proves the server's identity to the client. Mutual TLS also makes the client present a certificate, so both sides cryptographically prove who they are. It is the strongest machine-to-machine authentication and the default inside zero-trust service meshes (Phase 5). The cost is certificate lifecycle management — issuing, distributing, rotating, and revoking client certs at scale — which is why mTLS is common for internal service-to-service traffic and high-assurance partners, less so for public developer APIs.

• Control it satisfies: strong, mutual machine authentication with no shared bearer secret to leak.
• Evidence: the certificate authority configuration, cert inventory with expiry, rotation automation, and revocation (CRL/OCSP) proof.

Authorization: deciding what the caller may do

Authentication tells you the caller is user 42. Authorization decides whether user 42 may read invoice 9001. There are three models, in increasing order of expressiveness.

RBAC — Role-Based Access Control

Access is granted to roles, and users are assigned roles. "Admins can delete users; analysts can read reports." Simple, auditable, and the right default for most APIs. Its limit: roles are coarse. "Analyst can read reports" cannot express "analyst can read reports for their own region" without inventing a role per region, which explodes.

ABAC — Attribute-Based Access Control

Access is decided by attributes of the user, the resource, and the context — evaluated as a policy. "Allow if user.department == resource.department AND request.time is business hours AND user.device is managed." ABAC expresses fine-grained, contextual rules RBAC cannot, at the cost of more complex policy and harder reasoning about "who can access what."

ReBAC — Relationship-Based Access Control

Access is decided by the relationship between the user and the resource — "you can edit a document if you are its owner, or a member of a team it was shared with." This is the Google Docs / GitHub model, popularized by Google's Zanzibar. ReBAC shines when permissions follow a graph of ownership and sharing rather than fixed roles or attributes.

MODEL   DECIDES ACCESS BY        BEST WHEN                         WATCH OUT FOR
-----   ------------------       --------------------------        ---------------------------
RBAC    role -> permission       roles are stable and coarse       "role explosion" when you
                               (admin/editor/viewer)             need per-tenant/per-region rules
ABAC    attributes + policy      access depends on context         policy sprawl; hard to answer
                               (dept, time, device, region)      "who can access X?" at a glance
ReBAC   relationship in a graph  ownership/sharing drives access   needs a relationship store;
                               (docs, repos, multi-tenant)       overkill for simple role apps

Most real systems combine them: RBAC for the coarse cut (admin vs user), then ABAC or ReBAC for the fine-grained, per-resource decision. Whatever you choose, the authorization check must happen on the server, on every request, against the specific object being accessed — never trust the client to enforce it.

The GRC throughline

A SOC 2 auditor testing logical access (CC6.1/CC6.2/CC6.3) does not care that you "use OAuth." They ask: show me the scope catalog and a sample of issued tokens with their lifetimes; show me the role-to-permission matrix and prove the analyst role cannot reach admin endpoints; show me the API key inventory with rotation dates; show me that a request for someone else's object is denied. Each auth choice in this lesson is only as good as the evidence you can export to prove it operates. In the next lesson you will choose the right pattern for eight scenarios; after that, the OWASP Top 10 shows exactly how these controls fail when they are missing or misapplied.