Authentication vs Authorization: The Two Most-Confused Words in Security

Same prefix, completely different jobs

You add a login page, users sign in, and you breathe out. The app feels secure. Then a junior engineer signs in with their own valid account, changes the URL from /orders/42 to /orders/43, and sees someone else's invoice. Nothing was "hacked", every request had a valid session. The login worked perfectly. The problem was never login at all.

That gap is the difference between authentication and authorization. They share a prefix, they sit next to each other in the request, and they get used interchangeably in standups, which is exactly why people ship the bug above. Once you can keep them apart in your head, a huge class of security mistakes simply stops happening.

Two questions, in order

Authentication (authn) answers "who are you?", it proves identity. Authorization (authz) answers "what are you allowed to do?", it grants or denies access to a specific action or resource. Authn always runs first; authz depends on its answer.

Notice the ordering. You cannot decide what someone is allowed to do until you know who they are. But knowing who they are tells you nothing, on its own, about what they may do. Those are two separate decisions, made at two separate moments, often by two separate parts of your system.

Your passport is real whether you are flying to Tokyo or standing in a parking lot, identity is stable. The boarding pass is scoped: one flight, one seat, one day. That scoping is the whole point of authorization, and it is why "they logged in" is never a complete answer to "should they be able to do this?".

Where each check lives in a request

Every protected request runs the same gauntlet. The client presents a credential, the server verifies it to establish identity, then a separate step asks whether that identity may perform this exact action on this exact resource. Only if both pass does your business logic ever run.

1. 1

   Client sends a credential

   A request arrives carrying proof of identity, a session cookie, a bearer JWT in the Authorization header, or an API key. No credential at all means the request is anonymous.

2. 2

   Authenticate: who are you?

   The server validates the credential, verifies the JWT signature and expiry, or looks up the session ID in its store. Success yields a trusted identity (a user id, maybe roles/scopes). Failure returns 401 Unauthorized and stops here.

3. 3

   Authorize: allowed for THIS?

   Now that identity is known, a policy check asks whether this user may perform this specific action on this specific resource, not "are they logged in" but "may user 42 delete order 43?". Failure returns 403 Forbidden.

4. 4

   Handler runs

   Only after both gates pass does the actual business logic execute. By the time your handler runs, identity is proven and the action is permitted, the handler should not have to re-litigate either.

Sessions vs tokens: how identity is carried

Authentication does not stop after login, proof of identity has to ride along on every subsequent request, because HTTP is stateless. There are two dominant ways to carry it, and they make opposite trade-offs.

Sessions are server-side. After login the server creates a session record (in memory, Redis, or a database) and hands the client an opaque session ID in a cookie. Every request sends the cookie; the server looks the ID up to recover the identity. The token itself carries no information, it is just a key into server state. Revoking access is trivial: delete the row.

Tokens (typically JWTs) are self-contained. After login the server signs a token that embeds the claims, user id, roles, expiry, and the client sends it on each request. The server verifies the signature and trusts the contents without a lookup, which scales beautifully across many services. The catch: a signed token is valid until it expires, so you cannot easily revoke one mid-flight. That is why access tokens should be short-lived and paired with a refresh token.

OAuth and OIDC, without the jargon

Two more terms get tangled into the authn/authz knot, so let us untangle them in one breath. OAuth 2.0 is an authorization framework, it lets a user grant one app limited access to their data in another app without sharing a password. When you click "Connect your Google Calendar", OAuth is what issues an access token scoped to just your calendar.

OIDC (OpenID Connect) is an authentication layer built on top of OAuth. It adds an id_token, a JWT that proves who the user is, so apps can use "Sign in with Google" for login, not just data access. Rule of thumb: OAuth = delegated authorization (access to resources); OIDC = federated authentication (proof of identity). Most "Sign in with X" buttons are OIDC; most "Allow X to access your Y" consent screens are OAuth scopes.

The scopes you see on those consent screens (read:calendar, email, profile) are authorization data riding inside an authentication flow. Your app should treat scopes as one input to its own policy decisions, not as the final word on what a user may do inside your system.

In code: verify identity, then check permission

Here is the whole idea in one Python handler. The first block proves identity from a JWT (authentication). The second block, a completely separate decision, asks whether that proven identity may act on this particular resource (authorization). Keep them visibly distinct.

import jwt  # PyJWT
from fastapi import HTTPException, Request

JWT_SECRET = "...load-from-env..."

# --- AUTHENTICATION: who are you? ---
def authenticate(request: Request) -> dict:
    header = request.headers.get("Authorization", "")
    if not header.startswith("Bearer "):
        # No credential at all -> we don't know who you are.
        raise HTTPException(status_code=401, detail="Missing token")
    token = header.removeprefix("Bearer ")
    try:
        # Verifies signature AND expiry. Returns the claims if valid.
        claims = jwt.decode(token, JWT_SECRET, algorithms=["HS256"])
    except jwt.InvalidTokenError:
        raise HTTPException(status_code=401, detail="Invalid token")
    return claims  # e.g. {"sub": "42", "roles": ["customer"]}


# --- AUTHORIZATION: are you allowed to do THIS? ---
def authorize_order_access(user: dict, order) -> None:
    is_owner = order.customer_id == user["sub"]
    is_admin = "admin" in user.get("roles", [])
    if not (is_owner or is_admin):
        # We know exactly who you are -- you still can't have this.
        raise HTTPException(status_code=403, detail="Forbidden")


async def get_order(request: Request, order_id: str):
    user = authenticate(request)              # 1. prove identity
    order = await db.orders.find(order_id)
    if order is None:
        raise HTTPException(status_code=404)
    authorize_order_access(user, order)        # 2. check permission
    return order                               # 3. only now: business logic

The authorization check is resource-scoped: it compares the resource's owner against the caller. That is what stops the /orders/43 attack from the intro, a valid token authenticates the attacker, but they are not the owner, so authorize_order_access returns 403. The bug at the top of this article is exactly an app that ran step 1 and skipped step 2.

This pattern of "is the caller the owner, or do they have a role that overrides it?" is RBAC (role-based access control). When rules get richer, "managers can refund orders under €500 in their own region", you graduate to ABAC (attribute-based access control), where the decision is a function of attributes of the user, the resource, and the context. Same place in the request; just a more expressive policy.

Common mistakes that ship security holes

1. Assuming authentication implies authorization. "They're logged in" is not "they may do this." Every protected action needs its own permission check against the specific resource, the single most common real-world breach (broken object-level authorization, the /orders/43 bug).
2. Enforcing authorization only in the UI. Hiding the Delete button for non-admins is UX, not security. The endpoint is still reachable with curl. Every check that hides a button in the frontend must be re-enforced on the server, where it cannot be bypassed.
3. Long-lived or non-revocable tokens. A JWT with a 30-day expiry and no denylist means a leaked token is a 30-day master key. Keep access tokens short (minutes), use refresh tokens, and have a revocation path for the cases that matter.
4. Trusting claims you didn't verify. Decoding a JWT is not verifying it. Always check the signature and expiry (and issuer/audience) before trusting a single claim, an unverified "roles": ["admin"] is just attacker-supplied JSON.
5. Checking permissions far from the resource. Authorization decided at the gateway with stale role data can drift from reality. Decide as close to the protected resource as you can, with current data.

Takeaways

Where to go next

Authn and authz are the spine of every secure system, but they live inside a bigger picture. Two natural next steps: see how these checks fit into a hardened API surface, and how identity stops being a one-time gate and becomes a continuous decision.

• Secure API Design, where authn/authz sit among input validation, rate limiting, and safe defaults.
• Zero Trust Networking for Beginners, "never trust, always verify": authorization re-checked on every hop, not just at the edge.
• DevOps Engineer path, the role track where securing services and pipelines is part of the day job.