Authentication vs Authorization

If you are new here: Authentication and authorization are two words that get used interchangeably — incorrectly. They solve different problems and happen at different points in a request's lifecycle. Authentication (AuthN) is the step where a system verifies who you are: you prove your identity by presenting something you know (a password), something you have (a TOTP code from an authenticator app), or something you are (a fingerprint). Only once your identity is confirmed does authorization (AuthZ) kick in — the step that determines what you are allowed to do: can you read invoices? delete users? access the admin panel? Getting these two steps confused, or conflating them in code, is one of the most common sources of security vulnerabilities.

The Problem

Imagine a web application that just… trusts whoever calls it. No login, no checks. Anyone who can reach the API can read any user's data, delete records, or access the admin dashboard. Obviously broken — but the insidious version is partial protection: the app requires a login but then doesn't check whether the logged-in user is allowed to see what they asked for.

A real example: in 2019, Instagram had an API endpoint that required authentication (you had to be logged in) but didn't properly check authorization (whether you could access this user's data). Authenticated attackers could read private posts and contact information belonging to other users. AuthN was fine. AuthZ was broken.

In plain terms: authentication without authorization is like checking someone's ID at the door of a bank, then letting them walk into any vault they want because "they proved they're a person." The ID check (AuthN) is necessary but not sufficient.

Analogy: A hotel keycard system. When you check in, the front desk verifies your identity and reservation (AuthN — who are you?). The keycard they give you is then encoded to only open your room and the gym (AuthZ — what are you allowed to access?). The keycard doesn't prove who you are — it just carries your permissions. A stolen keycard is an authorization problem; a stolen passport is an authentication problem.

Step 1 — Authentication: Proving Identity

Authentication is the process of confirming that you are who you claim to be. The three classical factors:

Something you know: a password, a PIN, the answer to a secret question. Passwords are the weakest factor — they can be guessed, phished, or leaked in data breaches. Password strength requirements and breach detection (checking passwords against known-leaked databases like HaveIBeenPwned) help.

Something you have: a one-time code from an authenticator app (TOTP), a hardware security key (YubiKey), a code sent to your phone. These are physical devices or time-sensitive codes the attacker would also need to possess, not just know.

Something you are: biometrics — fingerprint, Face ID, iris scan. These are convenient but have unique failure modes (you can't change your fingerprint if it's leaked; biometric data has privacy implications).

Multi-factor authentication (MFA): combining two or more factors. Even if a password is leaked, an attacker without the TOTP device can't authenticate. MFA is the single most effective individual security measure for preventing account takeover.

In plain terms: authentication is about trust establishment — building enough confidence that this request is genuinely from the claimed identity before doing anything with it.

Tiny example: you visit github.com/login. You enter your username and password (something you know). GitHub then asks for the code from your authenticator app (something you have). Both factors match → you're authenticated. GitHub now knows it's dealing with you, not an attacker who stole your password.

Step 2 — Authorization: Checking Permissions

Once identity is confirmed, every subsequent action still needs an authorization check: does this confirmed identity have permission to do what they're asking?

Authorization can be modeled in several ways:

Role-Based Access Control (RBAC): users are assigned roles (admin, editor, viewer). Roles have permissions (admin can delete; viewer can only read). The authorization check is: "does this user's role grant permission for this action on this resource?" Simple to manage, works well at small to medium scale.

Attribute-Based Access Control (ABAC): more flexible — policies combine attributes of the user, the resource, and the context. "A manager in region=EU can approve expenses up to €10,000 if business_hours=true." More expressive but harder to reason about.

ACL (Access Control List): a per-resource list of principals and their permissions. Google Drive uses this — each file has an ACL: "Alice: owner; Bob: can view; @company.com: can comment." Fine-grained but becomes unwieldy for thousands of resources.

In plain terms: authorization is the security guard at every door inside the building — not just at the entrance. Even authenticated users have a limited set of things they're allowed to do, and every operation should verify that limit is respected.

Concrete sketch: Alice (a billing_manager) is authenticated. She requests GET /api/invoices/INV-005. The authorization policy checks: does billing_manager role include invoices:read? Yes → allowed. She then requests DELETE /api/users/42. Policy checks: does billing_manager include users:delete? No → 403 Forbidden. The request never reaches the database.

The Correct Order: AuthN Then AuthZ

These two steps must happen in sequence — authentication before authorization — and neither can be skipped:

1. Authentication gate: reject unauthenticated requests immediately. If there's no valid identity token, return 401 Unauthorized. Don't even check permissions for anonymous requests to protected resources.

2. Authorization gate: for authenticated requests, check that the confirmed identity has permission for the specific action on the specific resource. Return 403 Forbidden if not.

Common mistakes:

• Missing AuthZ check: "the user is logged in, so they can access it" — ignores whether this user should access this resource. Classic horizontal privilege escalation: user 42 edits their profile at PUT /users/42, then manually changes the URL to PUT /users/43 and it works.
• AuthZ without AuthN: checking a user's role without verifying the identity token is valid — an attacker can forge a token that claims the admin role.
• Caching authorization decisions too aggressively: Alice is fired and her permissions revoked. If you cached "Alice is admin = true" for 24 hours, she still has admin access until the cache expires.

In plain terms: AuthN is "are you who you say you are?" AuthZ is "are you allowed to do what you're asking?" Both questions must be answered, in that order, on every sensitive request.

The Trade-offs

Authentication and authorization are orthogonal problems that happen to be applied together. Understanding them as distinct layers helps you debug access issues faster:

Why this matters for you

Every API you build needs both layers, applied in order. The practical checklist: (1) every protected endpoint has an authentication middleware that validates the token; (2) every operation that modifies or reads sensitive data has an explicit authorization check — not just "is the user logged in" but "does this user have permission for this resource." Build AuthN and AuthZ as composable middleware from the start; retrofitting them onto an unprotected system is painful and error-prone.

Next: Session vs Token Authentication — how to actually implement AuthN at scale: server-side sessions vs stateless signed tokens.