# Authentication vs Authorization: The Difference That Trips Everyone Up

Source: https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

Authentication and authorization sound alike and are often shortened to the same "authZ/authN," but they answer different questions. Getting them straight is foundational to identity.

## Authentication (AuthN): who are you?

Authentication **verifies identity**. It is the login step: passwords, [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), biometrics, and [multi-factor authentication](https://startwithidentity.com/vendors/mfa/). A successful authentication establishes a trusted session.

## Authorization (AuthZ): what can you do?

Authorization happens **after** authentication and decides what the verified identity is allowed to access. This is where [RBAC, ABAC, and ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/) models live.

## Why mixing them up is dangerous

A common flaw is treating "logged in" as "allowed." A user can be perfectly authenticated and still must be checked for permission on every sensitive action. Broken authorization is consistently among the most common and severe application vulnerabilities.

## Where it fits

Both are pillars of [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) and [Zero Trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/), where every request is verified (authN) and least-privilege checked (authZ).

## The failure looks like this

Broken authorization is consistently near the top of the OWASP list, and the shape is almost always the same. A request arrives with a valid session, the application confirms the user is logged in, and then reads an identifier from the request to decide what to return. Change the identifier and you get someone else's data. The user was perfectly authenticated the whole time.

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.

## Authorization models, briefly

Once you are checking properly, the question becomes how the rules are expressed:

- **[RBAC](https://startwithidentity.com/glossary/rbac/)** bundles permissions into roles. Readable and auditable, and prone to role explosion as every exception becomes a new role.
- **[ABAC](https://startwithidentity.com/glossary/abac/)** evaluates attributes of the subject, resource, action, and environment. Flexible, harder to audit, because "who can read this record" becomes a computation rather than a lookup.
- **[ReBAC](https://startwithidentity.com/glossary/rebac/)** derives access from relationships (owner, member, parent), which is what sharing and collaboration products actually need.

Most mature systems use roles for the coarse grant and attributes or relationships for the fine-grained condition. See [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/).

## Where the line blurs

[Claims](https://startwithidentity.com/glossary/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.

## Where to start

Browse [authentication and MFA vendors](https://startwithidentity.com/vendors/mfa/) and [authorization engines](https://startwithidentity.com/vendors/authorization/).