Authentication vs Authorization: The Difference, Explained Properly

Key takeaways

• Authentication verifies who. Authorization decides what they may do. The split is structural and the order is fixed: authenticate, then authorize.
• OAuth 2.1 is named an authorization framework but is most often used for authentication via OIDC layered on top. The naming has caused two decades of confusion.
• Authentication is identity-system territory (CIAM, workforce IAM). Authorization is policy-engine territory (RBAC, ABAC, ReBAC, OPA, Cedar).
• The classic integration bug is keying authorization off ID Token claims instead of access token scopes, or vice versa. Pick one per resource and enforce it.

The structural difference

The clean separation, side by side:

	Authentication	Authorization
Question	Who are you?	What may you do?
Input	A credential (password, passkey, OTP, certificate)	A verified principal, a requested action, a resource
Output	A verified identity (the principal)	A grant or denial
When	Once per session (or per high-stakes action)	Every authorized operation
Where	CIAM / IAM system	Application code, policy engine, API gateway
Failure mode	Reject the login	Reject the operation
Standard	OIDC, FIDO2, WebAuthn	OAuth 2.1 scopes, RBAC/ABAC/ReBAC models

In a real login flow, the sequence is:

1. User claims identity ("I am user@example.com").
2. Authentication: user presents credential (passkey, password+MFA, etc.); the CIAM verifies it; on success, a session is created and tokens are issued.
3. User requests an action ("delete this document").
4. Authorization: the application evaluates a policy — does this user have permission to delete this document? — and returns allow or deny.

Steps 2 and 4 are different operations handled by different parts of the stack.

Why OAuth confuses everyone

OAuth's full name is "OAuth 2.0 Authorization Framework". It is structurally an authorization protocol — the resource owner authorizes a client to access protected resources on their behalf. It deliberately omits authentication; the spec says nothing about who the user is, only that they have agreed to a client's request.

The confusion: OAuth is mostly used today as part of authentication. OIDC (OpenID Connect) layers identity claims on top of OAuth, producing the ID Token that tells the relying party who the user is. So in practice, the OAuth+OIDC bundle handles both authentication (OIDC's ID Token) and authorization (OAuth's access token), and the casual phrase "log in with OAuth" actually means "authenticate with OIDC, which uses OAuth as the substrate". The naming has caused two decades of conversations that start with "wait, is OAuth authentication or authorization?".

The clean answer: OAuth on its own is authorization. OIDC adds authentication. When someone says "we use OAuth for login," they almost always mean OIDC.

The classic integration bug

The most common authentication-vs-authorization integration bug: keying authorization decisions off the wrong token.

The shape of the bug:

• An OIDC flow produces two tokens: an ID Token (authentication — tells the relying party who the user is, intended for the client to consume at session creation) and an access token (authorization — tells the API which scopes the user granted, intended for the client to send to APIs).
• A backend API receives a request with a bearer token attached.
• The backend uses the ID Token to make authorization decisions ("does this user have role X?") — but the ID Token's audience is the client, not the API, and the ID Token doesn't contain authorization scopes.

The fix: separate the artifacts. ID Token consumed by the client at session creation; access token sent to APIs; authorization decisions in the API key off access token scopes and the validated subject (sub claim) plus the application's own permission model.

The mirror bug: using the access token's scopes to make authentication decisions ("the token has scope admin, so this user is an admin"). Scopes describe what the user authorized the client to do, not the user's role or attributes. Conflating scopes with roles in a complex authorization model is a fast path to bugs.

Where each lives in the stack

The clean architectural split:

Authentication lives in the CIAM (or workforce IAM) system. The CIAM owns the credential store, the MFA factors, the session model, the federation to upstream IdPs. Vendors: Auth0, WorkOS, Frontegg, MojoAuth, Microsoft Entra External ID, Keycloak (self-hosted), Clerk, Stytch.

Authorization lives in the application, with optional support from a policy engine. Standing roles and permissions (RBAC) often live in the CIAM; complex authorization (ReBAC for delegation, ABAC for attribute-driven policy, FGA for per-resource permissions at scale) lives in dedicated policy engines: OpenFGA, SpiceDB, Authress, Auth0 FGA, Ory Keto, Permify. Open Policy Agent (OPA) and AWS Cedar are general-purpose policy engines used for authorization across many systems.

The CIAM handles authentication exhaustively; the CIAM handles authorization only for simple RBAC. Once authorization requirements grow beyond "user has role" — once you need per-resource permissions, per-customer roles in B2B SaaS, delegated permissions for AI agents — the authorization decision migrates to a dedicated policy engine. The Fine-Grained Authorization (FGA) and RBAC vs ABAC vs ReBAC guides cover the model choice.

Practical guidance

• Pick one tool per concern. CIAM for authentication. Policy engine (or application code, for simple cases) for authorization. Don't make the CIAM do complex authorization; don't make the policy engine do authentication.
• Keep token use clean. ID Token at the client for identity. Access token at the API for scopes. Don't cross the streams.
• Authenticate at the edge, authorize at the resource. Edge gateway handles token validation and authenticated-identity propagation; the resource server makes the authorization decision based on the operation and the resource state.
• Audit both operations. Authentication audit log captures every login attempt (success and failure); authorization audit log captures every policy decision (grant and deny, with rationale). Both stream to SIEM.
• When in doubt, name the operation explicitly. "We authenticate the user via OIDC, then authorize the operation against an RBAC policy in OPA" is unambiguous. "We use OAuth" is not.