# authorization

Source: https://startwithidentity.com/glossary/authorization/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

Authorization (AuthZ) is the decision to permit or deny an authenticated subject access to a resource or action, and the rights that result; NIST's glossary, citing [CNSSI 4009-2022](https://csrc.nist.gov/glossary/term/authorization), defines it as "the decision to permit or deny a subject access to system objects (network, data, application, service, etc.)." Authentication (AuthN) comes first and answers who you are; authorization answers what you may do.

| | Authentication (AuthN) | Authorization (AuthZ) |
|---|---|---|
| Question | Who is this? | What may they do here, now? |
| NIST definition | "Verifying the identity of a user, process, or device" ([FIPS 200](https://csrc.nist.gov/glossary/term/authentication)) | The permit or deny decision above |
| Typical standards | Passwords, [passkeys](https://startwithidentity.com/glossary/passkey/), [OIDC](https://startwithidentity.com/glossary/oidc/), [SAML](https://startwithidentity.com/glossary/saml/) | [OAuth 2.0](https://startwithidentity.com/glossary/oauth/) scopes, [AuthZEN](https://startwithidentity.com/glossary/authzen/), policy engines |
| Models | Factors and assurance levels ([AAL](https://startwithidentity.com/glossary/aal/)) | [RBAC](https://startwithidentity.com/glossary/rbac/), [ABAC](https://startwithidentity.com/glossary/abac/), [ReBAC](https://startwithidentity.com/glossary/rebac/), [fine-grained authorization](https://startwithidentity.com/glossary/fga/) |
| HTTP failure | 401 Unauthorized (really "unauthenticated") | 403 Forbidden |

The common confusion is OAuth. OAuth 2.0 is an authorization framework: an access token says what a client may do, not who the user is. OpenID Connect adds an [ID token](https://startwithidentity.com/glossary/id-token/) on top of OAuth to carry authentication. Using an OAuth access token as proof of login is a classic integration bug.

It matters because most breaches after initial access are authorization failures: the attacker authenticated as someone real and the system let that identity do too much. Strong authentication with standing admin rights still fails; [least privilege](https://startwithidentity.com/glossary/least-privilege/), short-lived grants and decisions made per request, close to the resource, are the authorization side of the fix.

See also: [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [best authorization tools](https://startwithidentity.com/rankings/best-authorization-tools/), [scope](https://startwithidentity.com/glossary/scope/), [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/)