Authentication proves who you are; authorization decides what you are allowed to do. Authentication checks a claimed identity against factors such as a password, a passkey, or a fingerprint. Authorization then takes that confirmed identity and applies an access policy to decide which resources and actions it may use. Authentication always runs first, because there is nothing to grant permissions to until an identity is verified. A simple way to remember it: authentication is the ID check at the door, authorization is the list of rooms your badge can open.
What Is the Difference Between Authentication and Authorization?
Authentication verifies identity; authorization grants permission to that verified identity. The two appear together in almost every login, which is why they are so often blurred, but they answer different questions and fail in different ways.
Keeping them separate is not pedantry. The Open Worldwide Application Security Project (OWASP) ranks broken access control, which is failed authorization, as the number one risk to web applications. Many breaches happen when a system authenticates a user correctly but then fails to check what that user is allowed to reach.
What Is Authentication?
Authentication is the process of verifying that a user, device, or system is who or what it claims to be. When you enter a username you are making a claim; authentication is the proof that backs it. It checks one or more factors against records the system holds.
- Something you know: a password, a PIN, or a security answer.
- Something you have: a phone with an authenticator app, a hardware security key, or a smart card.
- Something you are: a fingerprint, a face, or an iris scan.
Combining two or more independent factors is multi-factor authentication, the single biggest lever on account security. The factors and methods are covered in full in what authentication is. A well-built system never stores your raw password; it stores a salted hash and compares hashes at login.
What Is Authorization?
Authorization is the process of granting a verified identity the specific permissions its role or attributes allow. It runs only after authentication has confirmed who the user is, and it applies an access policy to every request.
- Permission assignment: the verified identity is mapped to rights over specific resources and actions.
- Policy evaluation: the system checks the identity against rules such as roles, attributes, or access lists.
- Least privilege: each identity gets only the minimum access its job requires, which limits the damage of a stolen account.
- Enforcement: any action the policy does not permit is blocked, on every request, not just at login.
The rules authorization enforces are defined by access control models, covered in what access control is. The least-privilege principle is also the foundation of zero trust security, which treats every request as untrusted until proven otherwise.
In What Order Do Authentication and Authorization Run?
Authentication always runs before authorization, and the order can never reverse. A system has nothing to authorize until it knows who is asking. The flow below is the same whether you sign in to an email account or call an API.
- Identify. You present a claimed identity, such as a username or email.
- Authenticate. The system checks your factors against stored records and confirms, or rejects, who you are.
- Issue a session. On success it issues a token or cookie so you do not re-prove identity on every click.
- Authorize. For each resource you request, the system checks your confirmed identity against the access policy.
- Decide. It grants or denies that specific action based on the policy, and logs the result.
A request that fails step two never reaches step four. This is why a stolen password is dangerous: it passes authentication, and from there the attacker inherits whatever the account is authorized to do.
Why Are 401 and 403 Errors So Often Confused?
The HTTP status codes map directly onto the two concepts, but their names are misleading. This is the most common point of real-world confusion between authentication and authorization.
Which Protocols Handle Authentication and Authorization?
OAuth 2.0 handles authorization; OpenID Connect adds authentication on top of it. The two are frequently confused because they run together in most modern sign-ins, but each does a distinct job and issues a distinct token.
- OAuth 2.0 (authorization): the IETF framework (RFC 6749) that lets an app obtain a scoped access token to act on a resource on your behalf. It answers “what may this app do?” and does not, by itself, prove who you are. OAuth 2.1 is a draft that consolidates a decade of security best practice and is expected to replace it.
- OpenID Connect (authentication): an identity layer built on OAuth 2.0, maintained by the OpenID Foundation. It answers “who is this user?” by issuing an ID token. This is what powers “Sign in with Google” and similar buttons.
- Access token vs ID token: the access token (for the API) carries scopes that say what is permitted; the ID token (for the app) carries claims that say who the user is. RFC 9068 standardized the JWT access token format so it works across providers.
- SAML and SSO: single sign-on authenticates you once and then authorizes you across many connected applications, so one verified identity unlocks a whole suite.
What Are the Main Authorization Models?
Authorization decisions are driven by a model, and the two most common are RBAC and ABAC. Authentication does not vary much by model; authorization does, because the policy logic is where access rules live.
- Role-Based Access Control (RBAC): access follows the role a user holds, such as viewer, editor, or admin. It is simple to reason about and, per NIST SP 800-162, covers the needs of most enterprise applications.
- Attribute-Based Access Control (ABAC): access is decided from attributes of the user, resource, action, and environment, such as department, data classification, or time of day. It is finer-grained but more complex to build and maintain.
- Access control lists (ACLs): permissions are attached directly to each resource, listing exactly which identities may use it. This is common in file systems.
- Hybrid: many mature systems use RBAC for a baseline and layer ABAC on top for context-sensitive rules, getting simple defaults with fine-grained exceptions.
Last Thoughts on Authentication vs Authorization
Authentication and authorization are two steps in one access flow, not two names for the same thing. Authentication proves who you are by checking factors against stored records; authorization decides what that verified identity may do by applying an access policy. Authentication always runs first, because a permission decision needs a confirmed identity to act on. The clearest test of whether a system gets this right is what happens after a valid login: strong authorization keeps a verified user inside the exact boundaries their role allows.
Confusing the two leads to real failures, from the 401-versus-403 mix-up to the broken access control that tops the OWASP risk list. Treating authentication and authorization as distinct controls, each properly enforced, is what makes access control work. The hub on cybersecurity connects both to the wider set of defenses.
Key Takeaways:
- Authentication verifies who you are; authorization decides what you are allowed to do.
- Authentication always runs first, because authorization needs a confirmed identity to act on.
- HTTP 401 means unauthenticated (fix by logging in); 403 means authenticated but not permitted.
- OAuth 2.0 does authorization (access tokens with scopes); OpenID Connect adds authentication (ID tokens).
- RBAC grants access by role; ABAC decides from user, resource, action, and environment attributes.
- Broken access control, a failure of authorization, is OWASP’s top web application risk.
Frequently Asked Questions (FAQs)
What is the difference between authentication and authorization?
Authentication verifies who a user is by checking factors such as a password or a passkey. Authorization decides what that verified user is allowed to do by checking their identity against an access policy. Authentication runs first, because authorization needs a confirmed identity before it can grant permissions.
Which comes first, authentication or authorization?
Authentication always comes first. A system must confirm who you are before it can decide what you may access, so a request that fails authentication never reaches the authorization step. The order is fixed because authorization has no identity to evaluate until authentication completes.
Does OAuth do authentication or authorization?
OAuth 2.0 is an authorization framework: it lets an app get a scoped access token to act on a resource, but it does not verify who the user is. OpenID Connect, an identity layer built on top of OAuth 2.0, adds authentication by issuing an ID token that proves who the user is.
What is the difference between a 401 and a 403 error?
A 401 is an authentication failure: the request lacks valid credentials, so logging in should fix it. A 403 is an authorization failure: you are authenticated, but you are not permitted to access that resource. Despite its name, 401 “Unauthorized” actually means unauthenticated.
What is the difference between RBAC and ABAC?
RBAC grants access based on the role a user holds, such as editor or admin. ABAC decides access from attributes of the user, resource, action, and environment, such as department, time of day, or data classification. RBAC covers most enterprise needs; ABAC adds fine-grained, context-aware control.
Can you have authorization without authentication?
Not meaningfully. Authorization assigns permissions to a confirmed identity, so without authentication there is no identity to grant rights to. The one exception is deliberately public access, where a resource is open to everyone and no identity check is needed.
