Authentication vs authorization.
Authentication (authN) proves who an identity is — it answers "are you who you claim to be?" Authorization (authZ) decides what that authenticated identity is allowed to do — it answers "are you permitted to do this?" Authentication always happens first; authorization happens on every access decision that follows.
Authentication (authN) vs Authorization (authZ).
| Dimension | Authentication (authN) | Authorization (authZ) |
|---|---|---|
| Question answered | Who are you? | What may you do? |
| Runs | Once, at login | On every protected access decision |
| Mechanisms | Passwords, MFA, passkeys, certificates, biometrics | RBAC, ABAC, ReBAC, scopes, policy engines |
| Protocols | OIDC, SAML, WebAuthn/FIDO2 | OAuth 2.1 scopes, XACML, OPA/Rego, Cedar |
| Produces | An identity (ID token, assertion, session) | A decision (allow / deny) |
| Failure mode | Impersonation, account takeover | Privilege escalation, broken access control |
Why the order matters
You cannot authorize an identity you have not authenticated. The system first establishes who is making the request (authentication), then evaluates what that identity is permitted to do (authorization). Conflating the two is the root of a large share of access-control vulnerabilities.
In a typical OIDC + OAuth flow this maps cleanly: OpenID Connect handles authentication (the ID token proves who the user is), and OAuth 2.1 access tokens carry the scopes that drive authorization (what the client may call).
The classic integration bug
The most common authN/authZ mistake is keying authorization off the wrong token. The ID token says who the user is — it is an authentication artifact and should not be sent to APIs as proof of permission. The access token carries scopes and is the authorization artifact. Code that authorizes API calls by inspecting ID-token claims (or, worse, accepts an ID token as a bearer credential) is mixing the two layers and usually has a privilege-escalation hole.
- Authenticate with the ID token; authorize with the access token scopes.
- Never send the ID token to a resource server as a bearer credential.
- Validate the access token audience (aud) so a token minted for one API cannot be replayed at another.
When to use each.
You are solving authentication when…
- You need to verify a user or service is who it claims to be.
- You are choosing factors (passkeys, MFA) or an assurance level (NIST AAL).
- You are integrating SSO / federation (OIDC, SAML).
You are solving authorization when…
- You need to decide whether an authenticated identity can perform an action.
- You are choosing an access model (RBAC, ABAC, ReBAC).
- You are externalizing policy to a decision point (OPA, Cedar).
Common questions.
Is authentication or authorization more important?+
Neither — they are sequential layers of the same control. Authentication without authorization lets anyone who logs in do anything; authorization without authentication has no trustworthy identity to evaluate. A complete access-control system needs both.
Does OAuth handle authentication or authorization?+
OAuth 2.0/2.1 is an authorization framework — it issues access tokens that grant scoped access. It is not an authentication protocol. OpenID Connect (OIDC) is the authentication layer built on top of OAuth; it adds the ID token that proves who the user is.
What is the abbreviation for authentication and authorization?+
Authentication is commonly abbreviated authN (the "n" from authentication) and authorization as authZ (the "z" from authorization). The abbreviations exist precisely because the full words look so similar.
The whole picture, in one place.
This explainer is part of our complete guide to IAM — authentication, authorization, governance, privileged access, the standards, and how to run a program.