The Mechanics of Modern Authentication
Trace every authentication flow from the inside: session mechanics and cookie attributes, API key generation and constant-time validation, stateless token architecture and storage trade-offs, OAuth 2.0 authorization code and client credentials grants, PKCE for public clients, JWT structure and signing with HMAC and RSA, verification attacks and defensive implementation, access and refresh token rotation, OpenID Connect identity layer, and single sign-on cross-domain session architecture.
See the Invisible
Interactive simulators visualise what's hidden from view.
Hands-On Labs
Step through executions tick by tick. Manipulate state.
Why, Not Just What
Understand the reasoning behind every design decision.
Quizzes & Cheatsheets
Verify your understanding and keep a quick reference handy.
Get Certified
Earn a shareable certificate to prove your deep expertise.
Become the Engineer Who Supervises AI
As AI generates more code, understanding what that code does becomes more valuable, not less. Someone must verify AI output, debug failures, and make architectural decisions.
Build Your Architectural EdgeYou ship auth code you've never actually watched execute.
You configure authentication flows you've never actually traced
You've wired up OAuth redirects, set JWT expiration times, and
configured cookie attributes across multiple projects. But when a
token fails validation in production, when a redirect loop won't
resolve, or when a security review asks why you chose
SameSite=Lax over Strict, you're back to
piecing together blog posts and guessing. AI generates auth code
faster than ever, and you merge it because it looks right. The
problem: without seeing these flows execute step by step, you can't
distinguish correct from quietly vulnerable.
Simulations that make invisible auth flows visible
Every lesson includes a step-based visual simulation you can replay, pause, and reference on demand.
Trace every redirect, token, and cookie
Watch OAuth authorization code grants, PKCE exchanges, and session creation execute step by step so you can see exactly what travels between browser, authorization server, and resource server.
See attacks succeed before you learn to stop them
Watch algorithm confusion, the none algorithm
bypass, session fixation, and authorization code
interception play out visually, then see exactly how PKCE,
algorithm allowlisting, and constant-time comparison prevent
them.
Build mental models you can revisit in six months
Each simulation becomes a visual reference you carry to production. When you hit a token rotation bug or a cross-domain SSO issue months later, you can replay the exact flow instead of re-reading documentation from scratch.
What's Covered
From server-side sessions to cross-domain SSO, every authentication mechanism you'll encounter in production, traced end to end.
Configure server-side sessions, cookie security attributes
like HttpOnly and SameSite, and
API key validation with SHA-256 hashing, constant-time
comparison, and zero-downtime rotation.
Sign and verify tokens with HS256 and RS256, choose secure
client-side storage, and defend against algorithm confusion,
none algorithm bypasses, and stripped-signature
attacks per RFC 8725.
Trace every step of the Authorization Code grant, the
state parameter's CSRF prevention, Client
Credentials for machine-to-machine auth, and PKCE's
code_verifier/code_challenge
mechanism for public clients.
Architect short-lived access tokens with long-lived refresh tokens, implement Refresh Token Rotation with single-use chains, and detect token theft through reuse detection that revokes entire token families.
Establish user identity with OIDC ID tokens, validate claims against JWKS endpoints, and architect single sign-on with global IdP sessions, local SP sessions, and clear session lifetime boundaries.
The Curriculum
Comprehensive Lessons! Each with theory, interactive simulation, and quiz.
Session Authentication Mechanics
Credential submission, server-side session creation, and
session ID generation. Cookie-based session transport
with HttpOnly, Secure,
SameSite, Domain, and
Path attributes. Server-side storage
options: in-memory, distributed key-value stores like
Redis, and database-backed stores. Session expiration,
explicit invalidation, and horizontal scaling
constraints including sticky sessions, shared session
stores, and replication trade-offs. Session fixation
across authentication boundaries and session hijacking
via cookie theft.
API Key Authentication and Secure Validation
Generating high-entropy API keys with cryptographically secure random bytes. Prefix conventions for identifiability and automated secret scanning detection. Server-side storage via SHA-256 hashing with no plaintext persistence after initial display. Validation using constant-time comparison to prevent timing attacks that leak character-by-character match information. Key scoping to specific API endpoints and HTTP methods, and zero-downtime key rotation with concurrent old/new key windows.
Stateless Tokens and Token Storage Security
The stateless authentication model: embedding identity
claims in cryptographically signed tokens to eliminate
server-side session lookups. Token issuance after
credential verification, self-contained claim
validation, and the scalability advantage of independent
verification on any server instance. Client-side storage
trade-offs between HttpOnly cookies,
localStorage, and in-memory, with their
CSRF and XSS vulnerability profiles. The revocation
problem: tokens remain valid until expiration, requiring
blocklists or short lifetimes. Architectural trade-offs
between stateful session revocability and stateless
token scalability.
OAuth 2.0: Delegated Authorization and Grant Flows
The problem OAuth solves: third-party application access
to protected resources without sharing user credentials.
The four operational roles (Resource Owner, Client,
Authorization Server, Resource Server) and the trust
boundaries between them. The Authorization Code grant:
browser redirect with client_id,
redirect_uri, scope, and
response_type; user authentication and
consent; authorization code via redirect; back-channel
code-for-token exchange with client_secret.
The state parameter's CSRF prevention
mechanics. The Client Credentials grant for
machine-to-machine communication without user
delegation.
PKCE: Securing Public Clients from Code Interception
Confidential clients vs. public clients (SPAs, mobile
apps, desktop apps where
client_secret offers no protection). The
authorization code interception attack on shared
devices. PKCE mechanics: generating a high-entropy
code_verifier, deriving a
code_challenge via SHA-256, including the
challenge in the authorization request, and submitting
the original verifier during token exchange.
Authorization server verification by re-deriving the
challenge and comparing against the stored value. Why an
attacker possessing only the intercepted authorization
code cannot complete the exchange. PKCE as a mandatory
requirement per OAuth 2.0 Security Best Current
Practice.
JWT Structure and Signing Mechanics
The three-part base64url-encoded structure: Header
(algorithm, token type, key ID), Payload (claims), and
Signature. Standard claims (iss,
sub, aud, exp,
iat, nbf) and their validation
rules. Why base64url encoding provides no
confidentiality: payload contents are readable by anyone
who possesses the token. Symmetric signing with HS256
(shared-secret HMAC) vs. asymmetric signing with RS256
(private key signs, public key verifies). JSON Web Key
Sets (JWKS) endpoints for dynamic public key fetching
and key rotation via the kid header claim.
JWT Verification Attacks and Defensive Implementation
The algorithm confusion attack: submitting the server's
public RSA key as an HMAC symmetric secret to forge
valid signatures on tokens the attacker controls. The
none algorithm bypass: crafting tokens with
alg set to none and an empty
signature segment. The stripped-signature variant.
Defensive implementation per RFC 8725: explicit
algorithm allowlisting on the verifier side (never
trusting the token's header to select the algorithm),
rejecting tokens with unexpected or missing algorithms,
enforcing asymmetric verification for asymmetric keys,
and mandatory claim validation including
aud, iss, and
exp checks before processing any payload.
Access Tokens, Refresh Tokens, and Rotation Mechanics
Architectural separation of short-lived access tokens
and long-lived refresh tokens. Why short access token
lifetimes limit the exposure window if a token is
intercepted. Refresh token storage requirements:
HttpOnly cookies or secure server-side
storage, never localStorage. The refresh
flow: detecting expiration, sending the refresh token to
the token endpoint, and receiving a new access token.
Refresh Token Rotation (RTR): each successful refresh
issues a new token and invalidates the previous one,
creating a single-use chain. Reuse detection: when a
previously invalidated refresh token is presented, the
authorization server revokes the entire token family and
all descendant tokens.
OpenID Connect: The Identity Layer Over OAuth
The distinction between authorization (OAuth 2.0: what
resources can a client access) and authentication (OIDC:
who is the user). OIDC-specific scopes:
openid (triggers ID token issuance),
profile, and email. The ID
Token: a JWT containing identity claims
(sub, name,
email, nonce,
auth_time) intended for the client
application, not for resource server authorization. ID
Token validation: signature verification against the
provider's JWKS, nonce comparison for replay prevention,
audience and issuer checks, and expiration validation.
The UserInfo endpoint for additional claims.
Establishing a local application session from verified
ID Token claims.
Single Sign-On: Cross-Domain Session Architecture
Identity Providers (IdP) and Service Providers (SP) in a
single sign-on topology. The SSO session model: a global
session at the IdP and independent local sessions at
each SP. First-login mechanics and subsequent SP access
where the IdP recognizes the existing global session
cookie and returns an authorization code without
prompting for credentials. Cross-domain cookie
limitations: why applications on different domains
cannot share session cookies and must redirect through
the IdP. Session lifetime management with independent
expiration, prompt=login for forced
re-authentication, and max_age for
enforcing maximum authentication age. The single logout
problem: propagating session termination from one SP to
the IdP and then to all other SPs with active local
sessions.
Authentication architecture you can trace from login to token to cross-domain session
When auth breaks in production, when a security review questions your token handling, or when AI suggests an OAuth implementation, you'll trace every step in your head and know whether it's correct. This Deep Dive gives you the visual working knowledge of sessions, JWTs, OAuth, PKCE, and SSO that you carry directly to every architecture decision.
Ready to see what's really happening?
All deep dives included with your subscription. Cancel anytime.