Authentication & Sessions · Server Responsibilities Deep Dive

Quick Facts

At a Glance

Basic Concepts

Authentication (AuthN): proving identity — "you are who you say you are."
Authorization (AuthZ): deciding what an identity is allowed to do (separate concern — see its own page).
Session: server-remembered state tying subsequent requests back to a logged-in user.
Token: a self-contained credential the client carries on every request.
Identity Provider (IdP): the system of record for users — Okta, Auth0, Entra ID, Cognito, your own DB.

Mechanics

Sessions vs Tokens

Server-Side Sessions

Server stores a session record (Redis, DB). The client holds only an opaque session_id in a cookie.

Pros: trivially revocable, small cookie, no secrets in the client.

Cons: needs shared session store across instances; sticky sessions get awkward at scale.

Stateless Tokens (JWT)

Server signs a JSON payload; client carries it. Server verifies signature on each request — no lookup needed.

Pros: horizontally scalable, friendly to microservices and mobile.

Cons: revocation is hard (use short TTLs + refresh tokens); payload is visible to whoever holds the token.

Protocols

The Standards

OAuth 2.0 & OpenID Connect (OIDC)

OAuth 2.0 is a delegation protocol — "let app X call API Y on my behalf." It issues access tokens. OIDC is a thin identity layer on top of OAuth 2.0 that adds an ID token (a JWT describing the user). If you want "Sign in with Google," you want OIDC.

Authorization Code + PKCE — the modern default for web & mobile apps.
Client Credentials — service-to-service (no user involved).
Device Code — TVs, CLIs, anything without a real keyboard.
Implicit / Resource Owner Password — deprecated. Don't use.

SAML

Pre-OIDC enterprise SSO standard, XML-based. Still everywhere in B2B and corporate IT. If your customer is a Fortune-500 buyer, expect a SAML integration request even in 2026.

JWT (JSON Web Token)

A signed, base64-encoded payload: header.payload.signature. Common claims: sub (user id), exp (expiry), iss (issuer), aud (audience).

Verify signature, expiry, issuer, and audience on every request.
Never accept alg: none. Pin allowed algorithms server-side.
Don't put secrets, PII, or anything large in the payload — it's readable by anyone who holds the token.

Passkeys & WebAuthn

Public-key credentials backed by the device (Face ID, Touch ID, Windows Hello, hardware keys). Phishing-resistant by design and rapidly becoming the default for new consumer apps. Supported by every major browser and platform.

API Keys

Long-lived shared secrets — fine for server-to-server when scoped, rotated, and stored in a secret manager. Not appropriate for end-user authentication.

Storage

Cookies, Headers, and Where Tokens Live

Where	Pros	Cons
HttpOnly cookie	Inaccessible to JS — strong against XSS. Browser auto-sends.	Needs CSRF protection (SameSite, double-submit).
Authorization header	Standard for APIs. No CSRF surface.	Client code must hold the token — XSS can read it.
localStorage	Easy.	Readable by any JS on the page. Avoid for sensitive tokens.
In-memory only	Disappears on tab close — minimal blast radius.	Lost on refresh; needs a refresh-token flow.

Hardening

Password & Account Security

Hash, Never Encrypt

Use argon2id, bcrypt, or scrypt. Never SHA-256 or MD5 alone.

MFA / 2FA

TOTP apps, WebAuthn, push approvals. SMS only as a fallback — SIM-swappable.

Rate Limiting

Per-IP and per-account. Lockouts after N failed attempts.

Breach Detection

Check new passwords against Have I Been Pwned's k-anonymity API.

Email Verification

One-time signed link; expire it. Never log the token.

Session Rotation

Issue a new session ID after login and on privilege changes — defeats fixation.

SSO

Single Sign-On in Practice

SSO lets a user authenticate once with an IdP and access many apps. Two flavors dominate: OIDC (modern, JSON, mobile-friendly) and SAML (XML, enterprise-entrenched). Most B2B SaaS supports both — Auth0, Okta, WorkOS, and Cognito package the integration so you don't write SAML XML by hand.

"SCIM" is the companion standard for syncing user accounts and groups from the IdP into your app — without it, customers manually create users twice.

Pitfalls

Common Mistakes

Long-lived JWTs with no revocation path. Pair short access tokens (5–15 min) with refresh tokens stored server-side.
Forgetting to validate aud / iss. A token issued for service A should not unlock service B.
Rolling your own crypto. Use a vetted library and a managed IdP unless authentication is your product.
Logging tokens or session IDs. They're credentials — treat them like passwords.
Mixing AuthN and AuthZ. "Logged in" ≠ "allowed to do this thing." Keep them separate.

Continue

Other Server Responsibilities

Authorization Validation Persistence Integrations Background Jobs ↑ Back to Server Side