Authentication vs Authorization

Authentication answers who are you? (verify identity — usually a password, an OTP, a WebAuthn key). Authorization answers what can you do? (permission checks against an identity that’s already proven). Getting them confused is a classic security bug: authenticating a user and then failing to check their permissions — or worse, checking permissions against unverified identity. Modern systems layer both with a common vocabulary: a token establishes identity, an authorization policy (RBAC/ABAC) gates what that identity may do.

Session-Based vs Token-Based Auth

• Session auth — the server stores a session (server-side, e.g., in Redis/DB) and gives the client a session_id cookie. Revocable instantly, but the server holds state and cookies need HttpOnly/Secure/SameSite (see HTTP topic).
• Token auth — the server hands the client a token (JWT) that carries identity claims; the client sends it in an Authorization header on each request; the server verifies its signature. Stateless — no server-side session to store — which is why it scales for APIs. The catch: a leaked JWT is valid until expiry (short exp, rotation, and revocation lists are the mitigations).

JWT: Structure and the Signature

A JSON Web Token is three base64url parts joined by dots: header.payload.signature:

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0Iiwicm9sZSI6ImFkbWluIiwiZXhwIjoxNzAwMDAwMDAwfQ.3zF9...signature...

• Header — the algorithm (RS256 — asymmetric, verify with the public key).
• Payload — claims: sub (subject), iss (issuer), aud (audience), exp (expiry), iat (issued at), plus custom claims like role.
• Signature — HMAC(header.payload, secret) (HS256) or RSA/ECDSA-sign(header.payload) (RS256/ES256).

The security rules are strict: always verify the signature, always check exp, check aud (a token for one service must not be valid at another), and use a recent library — parsing without verifying is the classic JWT footgun. Store claims you trust, never secrets (a JWT is signed, not encrypted — its payload is readable by anyone who decodes it).

OAuth2: Delegated Authorization

OAuth2 lets an app act on behalf of a user without seeing their password — the authorization code flow, the pattern behind “Sign in with Google”:

1. The app redirects the user to the authorization server (/authorize?client_id=...&redirect_uri=...).
2. The user authenticates there (the app never sees the password) and consents to the requested scopes.
3. The server redirects back with a short-lived authorization code.
4. The app exchanges the code (with its client secret) for an access token (+ refresh token) at the token endpoint.
5. The app calls the resource server (e.g., the user’s calendar API) with the access token.

The code step is what keeps the password and the token off the browser; the refresh token lets the app get new access tokens without re-prompting the user.

PKCE extends the flow for public clients (SPAs, mobile): the app generates a random code_verifier, sends a hash (code_challenge) in the authorize call, and proves it at the token exchange — so a stolen authorization code is useless without the verifier.

OIDC and SSO

OpenID Connect (OIDC) is OAuth2 plus an ID token (a JWT) that authenticates the user — turning OAuth2’s “delegated authorization” into “also tell me who you are,” which is what enables Single Sign-On: one login at the IdP, and every participating app (OIDC/SAML) trusts the same identity. SAML is the enterprise predecessor (XML assertions), OIDC the modern successor (JWTs + JSON). SSO is why you log into Google once and every Google-integrated app recognizes you.

Authorization Models

• RBAC (Role-Based Access Control) — permissions attach to roles (admin, editor, viewer), and users are assigned roles. The standard for most systems: simple, auditable, easy to reason about. The trap is role explosion — too many bespoke roles become unmanageable.
• ABAC (Attribute-Based Access Control) — permissions are policies over attributes (user department, resource owner, time, location). More expressive, more complex; used where RBAC’s coarse roles aren’t enough (finance, healthcare).

The principle that underpins both: least privilege — grant the minimum access a user needs, no more. It’s the same rule in the System Design topic, applied to people.

MFA: Raising the Cost of Theft

A password is “something you know.” MFA adds “something you have” (TOTP app, WebAuthn/security key) or “something you are” (biometrics). WebAuthn (passkeys) is the modern best practice — a hardware-backed, phishing-resistant factor that never exposes a reusable secret. MFA is the single highest-ROI authentication control for real-world accounts.

The Visualizer

Use the OAuth visualizer above to step through the authorization-code and PKCE flows actor by actor: the user, the browser, the authorization server, and the resource server. Watch where the password is (and isn’t) seen, where the code is exchanged for the token, and how PKCE’s verifier binds the code to the app that requested it.

Practice Trajectory

1. Decode a real JWT’s header and payload (jwt.io) and verify its signature with the issuer’s public key.
2. Trace the authorization-code flow for a Google-style “sign in” and name where the password, the code, and the token each travel.
3. Explain why PKCE matters for an SPA where the client secret can’t be kept secret.
4. Design RBAC for an app with three roles and list the resources each role can touch; then explain one case where you’d reach for ABAC.
5. Turn on MFA for your accounts and identify which factor class (know/have/are) each one uses.

When It’s the Right Tool