Authentication vs Authorization (AuthN vs AuthZ) Explained

The difference between authentication and authorization is the question each answers: authentication (authn) verifies who you are, and authorization (authz) decides what you are allowed to do. Authentication happens at sign-in with a password, passkey or MFA. Authorization happens after it, and should run on every request, for every object. A user can be perfectly authenticated and still be denied.

The two are often shortened to the same "auth", which is how they get confused in code. Getting them straight is foundational to IAM.

Authentication vs authorization at a glance

The HTTP names are a historical trap. In RFC 9110, 401 means the request lacks valid authentication credentials, and the server must send a WWW-Authenticate challenge. 403 means the server understood the request but refuses it. Return 401 when you do not know who the caller is, and 403 when you do and the answer is no.

Authentication (authn): who are you?

Authentication verifies identity. It is the login step: passwords, passkeys, biometrics, and multi-factor authentication. A successful authentication establishes a trusted session. Strength varies a lot: phishing-resistant MFA such as passkeys resists the relay attacks that defeat SMS codes and push prompts. WebAuthn Level 3 became a W3C Recommendation on August 25, 2026.

Authorization (authz): what can you do?

Authorization happens after authentication and decides what the verified identity may access. This is where RBAC, ABAC, and ReBAC models live, and where OAuth scopes sit for APIs. The decision needs three inputs: the subject, the action and the specific resource. Checking only the first two is the bug behind most data leaks.

A worked example

An employee opens an expense app. The app redirects to the identity provider, which checks a passkey and returns an OIDC ID token: that is authentication. The app creates a session. The employee asks to view expense report 4471. The app calls its API with an OAuth access token scoped to expenses:read. The API must still ask: does report 4471 belong to this employee, or to someone they manage? That last check is authorization, and the scope alone does not answer it.

Why mixing them up is dangerous

A common flaw is treating "logged in" as "allowed." OWASP ranks it first: Broken Access Control is A01 in the OWASP Top 10:2025, and Broken Object Level Authorization is API1 in the OWASP API Security Top 10 2023, ahead of Broken Authentication at API2. The shape is the same each time: a request arrives with a valid session, the application reads an identifier from the request, and changing the identifier returns someone else's data.

Two rules prevent most of it:

• Check permission on the object, not the endpoint. "Is this user allowed to view invoice 4471" is a different question from "is this user allowed to use the invoice endpoint."
• Never trust an identifier the client supplied to select the record without an ownership or relationship check on the server.

Real failures on each side

Authorization failures:

• Optus, 2022. An internet-facing API returned customer personal information without valid authorization. About 9.5 million people were affected, per the Australian regulator (incident record).
• OAuth consent phishing. At Cyberhaven an employee with MFA authorized a malicious OAuth app and saw no MFA prompt, because a consent grant is authorization, not authentication (OAuth consent phishing).
• Grants that outlive the login. In the Salesloft Drift campaign, stolen refresh tokens for a third-party app worked as standing access to many Salesforce tenants with no user in the path (refresh token abuse).

Authentication failures:

• Forged tokens. Storm-0558 used a stolen Microsoft consumer signing key, and a validation flaw let those tokens open enterprise mailboxes.
• Unverified tokens. CVE-2026-48558 let attackers forge OIDC tokens against SimpleHelp servers that did not validate signatures, bypassing MFA (incident record). CVE-2023-29357 in SharePoint accepted alg: none JWTs.

Where the line blurs

Claims in a token are where authentication quietly becomes authorization. If your application reads a roles or groups claim and grants access on that basis, the integrity and freshness of that claim is now an authorization control: validate the signature, issuer, and audience, and remember that a token minted before someone left a group stays valid until it expires. Continuous access evaluation through the Shared Signals Framework closes that gap by pushing revocations to apps. When a grant needs more detail than a scope string can carry, such as one payment of a fixed amount to a named payee, Rich Authorization Requests (RFC 9396) put structured permission details in the token request itself.

Authorization models, briefly

• RBAC bundles permissions into roles. Readable and auditable, and prone to role explosion.
• ABAC evaluates attributes of the subject, resource, action, and environment. Flexible, harder to audit.
• ReBAC derives access from relationships (owner, member, parent), which is what sharing products need.

Most mature systems use roles for the coarse grant and attributes or relationships for the fine-grained condition.

Authentication and authorization tools

Authentication usually comes from an identity provider such as Okta, Microsoft Entra or, for customer apps, Auth0. Authorization is increasingly externalized to a policy engine: Open Policy Agent (whose creators and many Styra staff joined Apple in August 2025), OpenFGA, AuthZed, Cerbos, Permit.io, Amazon Verified Permissions ($5 per million single requests since a June 2025 price cut) and SGNL, which CrowdStrike acquired on February 20, 2026. The AuthZEN Authorization API 1.0, Final since January 11, 2026, gives apps one standard request format for any of them. Compare them in the best authorization tools ranking.

Where to start

Read OAuth vs OIDC for the protocol side, then browse MFA vendors and authorization engines.