I know, I know, this is pretty basic stuff, but for those who aren’t identity inclined, it’s necessary to cover.
I’ve been in enough architecture reviews, design sessions, and post-incident come-to-jesus moments to know that this confusion can cause some problems in security teams. Someone says “authentication” and meant “access control.” Someone says “authorization” and meant “login.” These words often get used interchangeably but if you’re building anything with access controls, you have to know the difference. If you don’t, the design gets built on a shaky conceptual foundation and six months later you’re doing a fire drill because users can see data they were never supposed to see.
So let’s cover the basics here and fix this once and for all.
Authentication: Proving Who You Are
Authentication (AuthN) is the process of verifying an identity. It answers one question: Are you who you say you are?
That’s it. Authentication does not decide what you can do, it just establishes that you are, in fact, you.
The mechanisms vary: Username/password, a FIDO2 key, a certificate, a biometric auth, an OIDC token from your IdP, etc. The method doesn’t really matter to AuthN, they all serve the same purpose even though some are more secure (read: harder to fake) than others. By the end of a successful authentication flow, the system has established a verified identity (meaning it has reason to believe beyond a reasonable doubt that you are you.).
What happens after that is not authentication’s problem and it doesn’t care.
Authorization: Deciding What You Can Do
Authorization (AuthZ) picks up where authentication leaves off. It answers the question: Now that we know who you are, what exactly are you allowed to do?
This is where access control types live: Role-based (RBAC), Attribute-based (ABAC), Policy-based (PBAC), etc. Again, it doesn’t really matter what flavor you use, it’s all authorization. The system at this point takes the verified identity from the authentication step, evaluates it against some set of rules or policies set up by the organization, and produces a decision: permit or deny.
Authorization takes this decision a step further and become contextual in a way that authentication doesn’t. Meaning the same user with the same identity, accessing a different resource in a different time of day from a different network location might recieve a different decision every time (assuming they’re using adaptive access with risk signals).
Why this Confusion Exists (And Why It Matters)
Here’s the why I think these two often get confused: in simple systems, these concepts often happen in the same place at the same time. You log in to an IdP with SSO, the IdP checks your password, maybe MFA, then it decides what you see. AuthN and AuthZ are both handled in one blob of middleware, so they feel like the same thing, but they’re not.
The moment you build anything with:
- Multiple backend services
- An API gateway
- External or federated identity providers
- Fine-grained resource permissions
- Non-human principals (service accounts, workload identities)
Then the distinction stops being academic and becomes a design constraint you cannot ignore. At that point you MUST understand which system(s) do which action
Consider a zero trust architecture. The whole premise is that network location doesn’t imply trust by default. You must authenticate every request and authorize every resource access independently. With a zero trust implementation, every downstream resource must know A) how to re-validate an identities authorization to a resource and B) how to consume that authorization at the point of access.
The “Confused Deputy” Is an AuthZ Failure, Not an AuthN Failure
Quick side note here because this comes up consitently in troubleshooting calls.
The confused deputy problem (a service acting on behalf of a user gets tricked into using its own elevated permissions to do something the user couldn’t do directly) is an authorization failure. The service was authenticated fine.. The problem is that the authorization wasn’t scoped properly. Knowing the difference between AuthN and AuthZ as well as what exactly is actually happening tells you exactly where to look so you can fix it in large environemnts.
The same goes for privilege escalation vulnerabilities and insecure direct object references (IDOR). These are all authorization issues.
Protocols Live in One Camp or the Other
This is a good sanity check if you’re ever feeling fuzzy on where something lives: Authentication protocols: SAML (authentication assertions), OIDC (the authentication layer built on OAuth), Kerberos, WebAuthn/FIDO2. These all produce a verified identity (an assertion that says “this service/user/human is who they claim to be.”) Authorization frameworks: OAuth 2.0 (it’s a delegation and authorization framework, not an authentication protocol), OPA, Cedar, Zanzibar-style systems if you’re spicy. These produce authorization decisions. “this service/user/human may or may not take this action on this resource.”
- NOTE: What about JWT?: Well JWT is neither. A JWT is just a token format that can carry authentication claims, authorization claims, or both. It is not and never was an authN or authZ protocol.
Practical Takeaway for Architects
When you’re designing a system, ask these questions explicitly and separately:
Authentication questions
- How does this principal prove their identity?
- Who issues the credential?
- How does the relying party validate it?
- What’s the token lifetime and revocation story?
Authorization questions
- What resources exist and what operations can be performed on them?
- Who makes the access decision: a centralized policy engine or the service itself?
- What claims from the identity token feed into the authorization decision?
- How do you handle context like time, location, risk signals?
If you’re getting answers that feel like they belong in the other bucket, that’s a design flaw. Something is leaking across a boundary it shouldn’t be.
TL;DR
- AuthN = proving identity. “Who are you?”
- AuthZ = access control. “What can you do?”
- They’re sequential, not synonymous. Authentication comes first then authorization uses the result.
- For example: OAuth 2.0 is an authorization framework. OIDC is the authentication layer. They work together but they are not the same.
- JWT is a format, not a protocol.