Authentication & Authorization

Authentication vs Authorization

Authentication answers one question: who are you? It verifies identity, that the entity making the request is who they claim to be. Authorization answers a different question: what are you allowed to do? It enforces policy, given a verified identity, what resources and actions are permitted.

They are separate concerns that happen in sequence. A system cannot make an authorization decision without first establishing identity through authentication. But authentication alone is never sufficient, knowing who someone is does not determine what they are allowed to do. Both must be correct for a system to be secure.

The sequence in practice

Common mistakes

Sessions vs Tokens

Once a user authenticates, the server needs a way to recognize them on subsequent requests. HTTP is stateless: every request is independent. Two mechanisms exist for maintaining authenticated state across requests, server-side sessions and client-side tokens.

Server-side sessions

On login, the server generates a random session ID and stores session data (user ID, role, expiry) in a server-side store (Redis, database). The session ID is sent to the client as an HttpOnly, Secure cookie. On every subsequent request, the browser sends the cookie automatically. The server looks up the session ID in the store to get the user's identity.

The session ID is opaque, it reveals nothing about the user. Revocation is instant: delete the session from the store and the user is logged out on the next request. The cost is the session store itself: every authentication check requires a network round trip to Redis, and horizontal scaling requires either sticky sessions (route each user to the same server) or a shared session store.

1. POST /auth/login { email, password }
   -> Server verifies credentials
   -> Server stores: sessions["abc123"] = { user_id: 42, role: "admin", exp: ... }
   -> Response: Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

2. GET /api/dashboard
   Cookie: session_id=abc123
   -> Server: redis.get("sessions:abc123") -> { user_id: 42, role: "admin" }
   -> Request proceeds as user 42

3. POST /auth/logout
   -> Server: redis.del("sessions:abc123")
   -> Cookie cleared
   -> User instantly logged out, next request finds no session

JWTs (JSON Web Tokens)

A JWT encodes identity and claims directly in a signed token that the client holds. The server verifies the signature on every request without consulting a store, the token is self-contained. This eliminates the session store and scales trivially across instances. Any server with the public key can verify any token.

The tradeoff is revocation. Because the server holds no state, a JWT is valid until its expiry (exp claim). If a user is compromised or logs out, the token remains valid until it expires. Solutions: short expiry (15 minutes) with refresh tokens, or a token blocklist (which reintroduces server state). Neither is as clean as session deletion.

Access tokens and refresh tokens

1. Login -> server issues:
   access_token:  short-lived JWT (15 min), sent in Authorization header
   refresh_token: long-lived opaque token (7 days), stored in HttpOnly cookie

2. API call:
   Authorization: Bearer <access_token>
   -> Server validates JWT signature, no DB lookup needed

3. access_token expires:
   POST /auth/refresh
   Cookie: refresh_token=<opaque_value>
   -> Server looks up refresh token in store (checks not revoked)
   -> Issues new access_token (15 min)

4. Logout:
   -> Server deletes refresh_token from store
   -> access_token expires naturally in <=15 min
   -> User cannot refresh -> effectively logged out

Sessions vs JWTs: when to use each

OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework. It allows a user to grant a third-party application limited access to their account on another service without sharing their credentials. The key insight is delegation: the user consents to a specific set of permissions (scopes), and the authorization server issues a token that represents exactly those permissions.

OAuth 2.0 is authorization only, it says what the token permits, not who the user is. OpenID Connect (OIDC) is a thin identity layer on top of OAuth 2.0 that adds an ID token (a JWT) containing the user's identity (sub, email, name). Most modern identity providers (Google, GitHub, Auth0, Okta) implement both: OAuth 2.0 for authorization, OIDC for authentication.

OAuth 2.0 grant flows

Scopes: the unit of delegation

Scopes define what a token is permitted to do. The client requests a set of scopes. The user consents to those scopes. The token carries only the consented scopes, the resource server checks them on every request. Scopes follow the principle of least privilege: request only what is needed.

OIDC: identity on top of OAuth 2.0

Authorization Models: RBAC, ABAC, ReBAC

Authorization is a policy problem: given a verified identity and a requested action, does this identity have permission? Three models dominate production systems, each expressing policy at different levels of sophistication. RBAC works for simple access control. ABAC handles context-dependent decisions. ReBAC models the relationship graphs used by collaborative applications.

roles = {
  viewer:  ["read:posts", "read:comments"],
  editor:  ["read:posts", "write:posts", "read:comments"],
  admin:   ["*"],  # all permissions
}

user.role = "editor"
can_edit = "write:posts" in roles[user.role]  # True

# Policy: editors can edit posts they authored;
# admins can edit any post;
# only during business hours in their timezone

def can_edit(user, post, context):
    if user.role == "admin":
        return True
    if user.role == "editor":
        authored = post.author_id == user.id
        in_hours = 9 <= context.local_hour < 18
        return authored and in_hours
    return False

# Google Zanzibar model:
# user:alice is viewer of document:plan
# user:alice is member of group:eng
# group:eng is editor of folder:projects
# document:plan is in folder:projects

# Question: can alice edit document:plan?
# -> alice member of eng
# -> eng editor of projects
# -> plan in projects
# -> YES (inherited through relationship chain)

Practical guidance