What is the difference between authentication and authorization?
Authentication (AuthN) and authorization (AuthZ) are sequential security steps that are often confused but solve distinct problems.
Authentication answers: who are you? It is the process of verifying that a claimed identity is genuine. A user presents credentials — a password, a cryptographic key, a hardware token, a biometric — and the system validates them against a stored record. Successful authentication establishes an authenticated identity. Mechanisms: password + hash comparison (bcrypt/argon2 on server side), OAuth 2.0 + OIDC for delegated authentication (Google/GitHub login), SAML for enterprise SSO, WebAuthn for passkeys, mutual TLS for service-to-service. After authentication, a session token or JWT is issued to represent the authenticated identity for subsequent requests.
Authorization answers: what are you allowed to do? It occurs after authentication and determines whether the authenticated identity has permission to perform a specific action on a specific resource. A user might be authenticated (the system knows who they are) but unauthorized to access a particular resource (they lack the required permission). Mechanisms: Role-Based Access Control (RBAC — roles assigned to users, permissions assigned to roles), Attribute-Based Access Control (ABAC — policies evaluate attributes of user, resource, and context), ACLs (per-resource permission lists), OAuth 2.0 scopes (token carries permitted actions). In REST APIs, authorization checks typically happen after validating the request's JWT/session token.
The practical consequence of conflating them: a system that only authenticates (checks that the user is logged in) but doesn't enforce fine-grained authorization will allow any authenticated user to access any resource — a classic BOLA (Broken Object Level Authorization) vulnerability. An attacker who is legitimately authenticated as user A modifies a request to access user B's data, and the server checks authentication (token is valid) but not authorization (does this token's user own this resource?).
The two-step flow in a typical web API: request arrives with a Bearer token → authentication middleware validates the token's signature and expiry → authorization layer checks whether the identity in the token has permission for the requested operation → request handler executes. These are separate concerns implemented at separate layers.
| Aspect | Authentication | Authorization |
|---|---|---|
| Question answered | Who are you? | What are you allowed to do? |
| Order | First step | After authentication succeeds |
| Failure result | 401 Unauthorized | 403 Forbidden |
| Common mechanisms | Password, OAuth/OIDC, WebAuthn, mTLS | RBAC, ABAC, ACLs, OAuth scopes |
| Token role | Establishes identity (JWT, session) | Token carries claims/scopes for authz checks |
| Attack if missing | Impersonation, credential theft | Broken object-level authorization (BOLA/IDOR) |
Correctly defines both terms with concrete examples, explains the sequential dependency (authz follows authn), and distinguishes 401 from 403 HTTP responses.
All of the above plus: names specific mechanisms for each (OAuth/OIDC for authn; RBAC/ABAC for authz), explains BOLA/IDOR as the vulnerability from missing authorization checks, and describes where each check happens in a typical request pipeline.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment