Authentication vs Authorization: What's the Difference?

Authentication and authorization are two distinct security steps that are easy to confuse because they almost always run back to back. Authentication answers who are you? while authorization answers what are you allowed to do? Getting the distinction right is the difference between a system that is merely locked and one that is actually secure.

What authentication is

Authentication (often shortened to authn) is the process of verifying that a party is who it claims to be. The classic mechanism is a username plus a secret the user knows, but modern systems combine several categories of evidence, traditionally described as factors:

• Something you know — a password, PIN, or passphrase.
• Something you have — a phone running an authenticator app, a hardware security key, or a smart card.
• Something you are — a biometric such as a fingerprint or face scan.

Multi-factor authentication (MFA) requires evidence from two or more of these categories, which is why a stolen password alone is no longer enough to break in. A common second factor is a time-based one-time code; you can see exactly how those rotate every 30 seconds with a TOTP 2FA generator. When the server stores credentials, it should never keep the raw password — it stores a slow, salted hash instead, the kind produced by a password hasher.

What authorization is

Authorization (often shortened to authz) is the process of deciding whether an already-identified party is permitted to perform a specific action on a specific resource. Once the system knows you are alice@example.com, authorization rules determine whether Alice can read a document, delete a record, or access an admin dashboard.

Authorization is typically expressed through one of a few models:

• Role-Based Access Control (RBAC) grants permissions to roles (admin, editor, viewer) and assigns users to roles.
• Attribute-Based Access Control (ABAC) evaluates rules against attributes of the user, resource, and environment (for example, "managers can approve expenses under $5,000 during business hours").
• Access Control Lists (ACLs) attach an explicit list of who-can-do-what directly to each resource.

Authentication vs authorization at a glance

A useful memory aid: the HTTP status code 401 is named "Unauthorized" but actually signals an authentication problem (we do not know who you are), while 403 Forbidden signals an authorization problem (we know who you are, but you are not allowed).

How they work together in a request

In a typical web API, the two steps fire in sequence on every protected request:

1. The client sends credentials, commonly a bearer token, in the Authorization header.
2. The server authenticates the token — checking its signature and expiry to establish identity.
3. The server then authorizes the request — checking whether that identity has permission for the requested operation.
4. If both pass, the request proceeds; otherwise it is rejected with a 401 or 403.

Confusingly, the HTTP header that carries the credential is literally named Authorization even though it is used for authentication. For simple username-password schemes the value is Base64-encoded, which you can produce with a Basic Auth header generator. For token schemes the value is usually a signed JSON Web Token (JWT).

Where JWTs fit

A JWT is a self-contained, signed token that bundles claims about the user — often an identifier, an issuer, an expiry, and a list of permission scopes or roles. The signature provides authentication (the server trusts the contents because the signature is valid), while the embedded scopes and roles feed the authorization decision. You can inspect any token's payload with a JWT decoder or craft test tokens with a JWT builder. For a deeper explanation of the format, see JWT tokens explained.

OAuth 2.0 is frequently mentioned alongside these terms, and the distinction matters: OAuth 2.0 is an authorization framework — it issues access tokens that grant scoped permission to call an API on a user's behalf. OpenID Connect is a thin authentication layer built on top of OAuth 2.0 that adds a verified identity (the ID token). The comparison in OAuth 2.0 vs JWT untangles which solves which problem.

Why the distinction matters

Treating the two as one step is a frequent source of vulnerabilities. A system can authenticate users perfectly and still leak data if it never re-checks authorization on each resource. The OWASP API Security project consistently ranks Broken Object Level Authorization and broken function-level authorization among the most common API flaws: the user is correctly logged in, but the server fails to verify they own the record they are requesting. Identifying the user is necessary but never sufficient.

Common pitfalls

• Authorizing on the client only. Hiding an admin button in the UI is not access control. Every permission check must be enforced on the server, because clients can be modified or bypassed.
• Trusting an unverified token. A JWT must have its signature validated and its expiry checked on every request. Decoding it without verifying the signature tells you what the token claims, not whether those claims are trustworthy.
• Insecure direct object references. Endpoints like GET /invoices/1043 must confirm the authenticated user is permitted to view invoice 1043, not just that they are logged in.
• Returning 401 when 403 is correct (or vice versa). Mixing the codes confuses clients and can leak whether a resource exists.
• Roles that drift over time. Permissions accumulate as people change teams. Periodic access reviews keep authorization aligned with the principle of least privilege.
• Skipping a second factor. Passwords are routinely phished and reused; MFA dramatically reduces account takeover even when a password leaks.

When you use each

You use authentication at every entry point where identity matters: signing in to an app, calling an API with a token, or establishing an SSH session. You use authorization on every individual action a known identity attempts thereafter. In practice they are inseparable in any real system — you authenticate once to establish a session or token, then authorize repeatedly as the user navigates and acts. Both steps also depend on a secure transport; without encryption in transit, credentials and tokens can be intercepted, which is why HTTPS is a non-negotiable foundation for both. If you are designing the API these checks protect, what is an API covers the surrounding fundamentals.

Frequently Asked Questions