Authentication verifies who you are. Authorization determines what you are allowed to do. Both are required for secure access control, but they are distinct processes that happen in a specific order.
TL;DR Authentication (AuthN) is the process of verifying identity — proving that a user, service, or device is who it claims to be. Authorization (AuthZ) is the process of determining what an authenticated entity is permitted to do. Authentication always happens first. Authorization happens second, after identity is confirmed. In APIs, authentication is typically handled with API keys, JWT, or OAuth 2.0. Authorization is typically handled with role-based or attribute-based access control (RBAC/ABAC).
Authentication vs authorization
| Authentication (AuthN) | Authorization (AuthZ) | |
|---|---|---|
| Question answered | Who are you? | What are you allowed to do? |
| Happens | First | Second (after authentication) |
| Validates | Identity | Permissions |
| Failure response | 401 Unauthorized | 403 Forbidden |
| Example | Logging in with username + password | Checking if a user can delete a resource |
| Protocols/standards | SAML, OIDC, LDAP, WebAuthn | OAuth 2.0, RBAC, ABAC, ACLs |
Authentication without authorization: you can verify who someone is but not control what they access. Authorization without authentication: you can set access rules but have no way to verify who is making the request.
Both are required. Authentication establishes identity. Authorization enforces access policy based on that identity.
How authentication works
Authentication answers the question: is this entity who they claim to be?
The most common authentication factors:
| Factor | Type | Example |
|---|---|---|
| Something you know | Knowledge | Password, PIN, security question |
| Something you have | Possession | TOTP app (Google Authenticator), hardware key (YubiKey), SMS code |
| Something you are | Inherence | Fingerprint, face recognition, voice |
Multi-factor authentication (MFA) requires two or more factors from different categories. MFA reduces account compromise risk by over 99% compared to passwords alone.
Authentication methods
| Method | How it works | Best for |
|---|---|---|
| Username + password | User submits credentials; server validates against stored (hashed) password | Web apps with user accounts |
| API key | Static token sent in header or query string; server maps key to identity | Server-to-server API access |
| JWT (Bearer token) | Server issues a signed token; client sends it in Authorization header | Stateless APIs, mobile apps, SPAs |
| OAuth 2.0 | Delegated authorization framework; issues access tokens on behalf of users | Third-party API access, SSO |
| SAML | XML-based identity federation; enterprise SSO across domains | Enterprise SSO, legacy systems |
| OpenID Connect (OIDC) | Identity layer on top of OAuth 2.0; issues ID tokens proving user identity | Modern SSO, social login |
| WebAuthn / Passkeys | Cryptographic key pair stored on device; no passwords | Phishing-resistant passwordless auth |
How authorization works
Authorization answers: what is this authenticated entity allowed to do?
After authentication confirms identity, the system checks whether that identity has permission to perform the requested action on the requested resource.
Role-Based Access Control (RBAC)
Users are assigned roles. Roles have permissions. Permissions are checked against the requested action.
User: maria@company.comRole: adminPermissions: read, write, delete
User: joao@company.comRole: viewerPermissions: readRBAC is simple to implement and audit. It works well when permissions map cleanly to job functions.
Attribute-Based Access Control (ABAC)
Permissions are determined by evaluating attributes of the user, resource, action, and environment at the time of the request.
Allow if: user.department == resource.department AND user.clearance_level >= resource.classification AND request.time is within business_hoursABAC is more flexible than RBAC and handles complex, context-sensitive policies. It is more complex to implement and audit.
Access Control Lists (ACLs)
A list of users or groups and their specific permissions on a resource. Common in file systems and network security.
Authentication in APIs
APIs use stateless authentication — the server does not maintain session state between requests.
Common API authentication patterns:
| Pattern | How it works | Trade-offs |
|---|---|---|
| API key | Client sends X-API-Key: <key> header | Simple; hard to rotate; no user identity |
| Bearer token (JWT) | Client sends Authorization: Bearer <jwt> | Stateless; self-contained claims; cannot revoke before expiry |
| OAuth 2.0 access token | Client obtains token via OAuth flow; sends as Bearer | Standard; supports scopes and delegation; complex setup |
| mTLS | Client presents certificate; server verifies | Strong mutual auth; common in B2B and IoT |
The standard HTTP response codes for access control failures:
401 Unauthorized— Authentication failed or missing. The client must authenticate.403 Forbidden— Authentication succeeded but the client lacks permission. Changing credentials won’t help.
Single Sign-On (SSO) and federated identity
SSO allows a user to authenticate once and access multiple applications without re-entering credentials.
How SSO works:
- User tries to access Application A.
- Application A redirects the user to the Identity Provider (IdP).
- User authenticates with the IdP (once).
- IdP issues an identity token (SAML assertion or OIDC ID token).
- Application A validates the token and grants access.
- User accesses Application B — which also trusts the same IdP — without re-authenticating.
Common SSO protocols:
- SAML 2.0 — XML-based; common in enterprise environments.
- OpenID Connect (OIDC) — JSON/JWT-based; built on OAuth 2.0; common in modern applications and social login.
Best practices
Authentication:
- Store passwords hashed with bcrypt, Argon2, or scrypt — never plaintext or MD5/SHA1.
- Enforce MFA for all user accounts, especially privileged ones.
- Use short-lived tokens (JWT access tokens: 5–60 minutes).
- Implement account lockout after repeated failed attempts.
- Use HTTPS for all authentication traffic — never transmit credentials over HTTP.
Authorization:
- Apply principle of least privilege: grant only the permissions required for the task.
- Validate authorization server-side — never trust client-supplied role or permission claims.
- Log all authorization decisions for audit trails.
- Review and rotate API keys and tokens regularly.
- Fail closed: deny by default; grant access explicitly.
Frequently asked questions
What is the difference between authentication and authorization? Authentication verifies identity — it answers “who are you?” Authorization verifies permissions — it answers “what are you allowed to do?” Authentication always happens first. A 401 HTTP response means authentication failed. A 403 means authentication succeeded but authorization failed.
What does “401 Unauthorized” actually mean? Despite the name, 401 Unauthorized means the request is unauthenticated — the client has not provided valid credentials or none at all. It’s a naming inconsistency in the HTTP spec. 403 Forbidden means the client is authenticated but lacks permission.
What is OAuth 2.0? OAuth 2.0 is an authorization framework that allows one application to access resources on behalf of a user in another application, without the user sharing their password. For example, “Login with Google” uses OAuth 2.0 to grant the app access to your Google profile without giving it your Google password.
What is the difference between OAuth 2.0 and OpenID Connect? OAuth 2.0 handles authorization — it issues access tokens that allow an app to access resources. OpenID Connect (OIDC) adds identity on top of OAuth 2.0 — it issues ID tokens that prove who the user is. OIDC is used for authentication (SSO, social login). OAuth 2.0 is used for authorization (API access delegation).
What is RBAC? RBAC (Role-Based Access Control) is an authorization model where users are assigned roles and roles have defined permissions. A user with the role “editor” can read and write; a user with the role “viewer” can only read. RBAC is simple to understand and audit, making it the most common authorization model in enterprise applications.
What is MFA and why does it matter? MFA (Multi-Factor Authentication) requires users to verify their identity using two or more independent factors — for example, a password plus a TOTP code from an authenticator app. Even if an attacker steals a password, they cannot authenticate without the second factor. MFA reduces account compromise risk by over 99%.
What is the difference between session-based and token-based authentication? In session-based authentication, the server stores session data and gives the client a session ID (usually in a cookie). Each request looks up the session on the server. In token-based authentication (JWT), the server issues a signed token containing all necessary claims. The client sends the token with each request; the server verifies the signature without any database lookup — enabling stateless, horizontally scalable authentication.
What is a passkey? A passkey is a cryptographic key pair generated on your device (phone, computer). The private key never leaves your device. When you authenticate, the device uses the private key to sign a challenge from the server. The server verifies with the public key. Passkeys are phishing-resistant (no password to steal or type) and the primary implementation of WebAuthn.