Two words, one letter apart. Conflating them is how verified users end up reading data they were never supposed to see. The Log4Shell aftermath, the Capital One breach, countless IDOR disclosures in HackerOne reports — an unsettling share of modern incidents trace back to a system that answered who are you? correctly and then failed silently on what are you allowed to do?
Authentication and authorization sit next to each other in every login flow, every API call, every OAuth handshake. They look like one step. They aren’t. This piece walks the distinction, the standards that govern each, and the architectural mistakes that come from treating them as a single concern.
What Each Word Actually Means
Authentication (often abbreviated AuthN) is the process of proving an identity claim. A user, service, or device asserts who they are, then produces evidence — a password, a hardware key, a signed assertion, a biometric — that only the legitimate party should possess. The system evaluates the evidence and decides whether the claim is credible.
Authorization (abbreviated AuthZ) is the process of deciding what an authenticated principal is permitted to do. Given a known identity and a requested operation on a resource, authorization returns allow or deny.
The order matters. Authentication runs first and produces a verified identity. Authorization runs afterward, repeatedly, every time that identity touches a protected resource. One login; thousands of authorization decisions.
The standards reflect this split. NIST SP 800-63B-4, finalized in July 2025, governs authentication — it defines three Authenticator Assurance Levels (AAL1, AAL2, AAL3) based on the strength of the verification factors used. NIST SP 800-162 governs authorization through its Attribute-Based Access Control (ABAC) guide. They are separate documents because they are separate problems.
How Authentication Actually Works
Every authentication system, regardless of sophistication, runs the same three-step loop.
First, the principal makes an identity claim — a username, an email, a client ID, a certificate subject. Second, they present one or more authentication factors: something they know (password, PIN), something they have (hardware token, phone), or something they are (fingerprint, face). Third, the system verifies the factor against a stored credential or a trusted authority and, on success, binds the verified identity to a session token or signed assertion.
Modern authentication has largely moved off passwords alone. Passkeys — synchronizable FIDO2 credentials, formally integrated into SP 800-63B-4 via the 800-63Bsup1 supplement — are replacing shared secrets with public-key cryptography. Hardware keys (YubiKey, Titan) satisfy AAL3. WebAuthn is the browser-side API that makes this work without passwords or SMS codes.
Once authentication succeeds, the system issues a proof of identity: a session cookie, a SAML assertion, or increasingly an OpenID Connect ID token. OIDC layers identity on top of OAuth 2.0 — it is the spec that defines the id_token JWT, the openid scope, and the /userinfo endpoint. OIDC is authentication; OAuth is not.
How Authorization Actually Works
Authorization consumes the verified identity and asks a second question: does this subject have permission to perform this action on this object?
There are four dominant models, each with tradeoffs worth understanding.
In practice, real systems blend these. An app might use RBAC for coarse role assignments, layer ABAC attributes on top for contextual decisions (deny writes outside business hours), and delegate fine-grained checks to an OPA sidecar.
Where OAuth Fits — And Where It Misleads People
OAuth 2.0, standardized in RFC 6749, is the most widely deployed authorization framework on the web. It lets a user grant a client application limited access to resources on a resource server without sharing the password. OAuth 2.1 — currently at draft-ietf-oauth-v2-1-15 as of March 2026 — consolidates OAuth 2.0 with PKCE (RFC 7636), deprecates the implicit and password grants, and bans bearer tokens in query strings. RFC 9700 is the current security best-current-practice.
Here is the confusion OAuth creates: the spec is about authorization — delegated access to a resource — but developers routinely reach for it to answer who is the user? Vanilla OAuth does not authenticate the end user to the client. The access token says “this request is authorized”; it does not say “this user is Alice.”
OpenID Connect exists precisely because of this gap. Add scope=openid to an OAuth request and the authorization server becomes an OpenID Provider, returning an id_token JWT with identity claims (sub, iss, aud, exp). That ID token is the authentication artifact. The access token remains the authorization artifact. Same handshake, two distinct outputs — one for each concern.
Treating an OAuth access token as proof of identity is one of the most common, and most exploitable, mistakes in modern app development. The token grants a capability; it does not assert a user.
How the Distinction Collapses in Practice
Real breaches rarely fail at the authentication step. Login screens are hardened; MFA is common; passkeys are winning. The failures cluster downstream, where authorization runs.
/invoice/1042 to /invoice/1043 reveals someone else’s data. OWASP’s #1 API security risk.read:* when they need read:profile. Compromise of the client means compromise of everything that token touches.Each of these is an authorization failure — the user is authenticated correctly, then granted access they should not have. Fixing authentication harder (more MFA, stronger passkeys, tighter session timeouts) does nothing for any of them.
How to Think About Them Going Forward
Treat the two concerns as separate subsystems with separate interfaces, separate failure modes, and separate logs. Identity belongs in one place — an IdP, a central auth service, a clearly-owned table. Authorization decisions belong somewhere the identity can be consumed but not forged: a policy engine, a middleware layer, a service that every request passes through.
The test is whether you can answer both questions about any production request: who made this request, and what was that subject allowed to do? If the logs conflate the two, or if one of them defaults to “trust the token,” the architecture has already lost the distinction. Most of what breaks in modern identity systems lives in that gap.
