Security

Authentication vs Authorization

Authentication vs authorization explained simply. Who you are versus what you are allowed to do, with real examples.

Authentication
Verifying Identity
VS
Authorization
Verifying Permissions
The short answer

Authentication answers who you are, usually through a password or token. Authorization answers what you are allowed to do, usually checked after authentication succeeds.

Authentication vs Authorization at a glance

AuthenticationAuthorization
Question answeredWho are you?What are you allowed to do?
HappensFirst, at loginAfter authentication, on every protected action
Typical mechanismPassword, OTP, biometric, tokenRoles, permissions, access control lists
ExampleLogging in with your email and passwordChecking if you can delete another user's post
HTTP status on failure401 Unauthorized403 Forbidden
Real world analogyShowing your ID at the doorThe ID deciding which rooms you can enter

When to use each

Choose Authentication when

  • You need to confirm a user is who they claim to be before granting any access.
  • You are building a login flow, password reset, or multi factor authentication.
  • You are issuing a session or token that represents a verified identity.

Choose Authorization when

  • You already know who the user is and need to decide what they can access.
  • You are building role based access like admin, editor, and viewer permissions.
  • You need to protect specific actions or resources from users who are logged in but not permitted.

A memorable way to separate them

Authentication is the bouncer checking your ID at the door. Authorization is the wristband that decides which sections of the club you can enter once you are inside. You always authenticate first, because you cannot decide what someone can do until you know who they are.

Where this shows up in code

In a typical web app, authentication middleware runs first and attaches the user's identity to the request, usually by verifying a token like a JWT. Authorization middleware runs after that and checks whether the identified user's role or permissions allow the specific action they are trying to perform.

In the interview

A sharp answer mentions the HTTP status codes. A 401 means you failed authentication, so the server does not know who you are. A 403 means you are authenticated but not authorized, so the server knows who you are and is refusing anyway.

Frequently asked questions

Can you be authorized without being authenticated?

Generally no. Authorization decisions depend on knowing who the user is, so authentication almost always has to happen first.

Is OAuth about authentication or authorization?

OAuth is primarily an authorization protocol, letting an app access resources on a user's behalf. OpenID Connect is built on top of OAuth specifically to add authentication.

What is role based access control?

It is a common authorization pattern where permissions are grouped into roles, like admin or editor, and each user is assigned one or more roles instead of individual permissions.

Want more interview ready comparisons?

Browse every Authentication vs Authorization style breakdown, or explore the full question library.

All comparisons Browse questions