OpenID Connect (OIDC) session replay is a high-value attack vector that slips past developers who trust the handshake too much. A replay happens when an attacker captures an ID token, access token, or session cookie, then reuses it to impersonate a valid user without re-entering credentials.
OIDC builds on OAuth 2.0, adding an identity layer with JWTs that convey authentication claims. These tokens are often short-lived, but session replay exploits the gap between token issuance and validation. If a token is intercepted—through exposed front-end code, insecure storage, or MITM attacks—it can be injected back into the system for unauthorized access.
Common weak points:
- Storing ID or access tokens in localStorage without encryption.
- Weak HTTPS enforcement, allowing packet capture.
- Missing audience (
aud) and expiration (exp) checks in the validation step. - Re-using refresh tokens without rotation or binding.
Mitigation requires defense in depth. Enforce TLS everywhere. Validate every token against issuer, audience, and expiry. Use Proof Key for Code Exchange (PKCE) and token binding to tie tokens to the client. Keep lifetimes short and rotate refresh tokens. Monitor session behavior for anomalies like geographic change or impossible travel events.
For high-impact environments, server-side session management beats pure client-side storage. Store only opaque references in the browser, match to server state, and invalidate aggressively. This makes captured tokens useless outside controlled context.
Session replay in OIDC is not solved by configuration alone—it demands active monitoring and rapid invalidation. When your threat model includes replay, every token-handoff step must be hardened.
See how hoop.dev captures, analyzes, and stops OIDC session replay before damage happens. Test it live in minutes.