Token Lifecycle Lab
A token breach is rarely a cracked signature — it is a lifecycle that was set up wrong. Work a queue of OAuth 2.0 / OIDC token setups and call each one: sound, or name the defect — an access token that lives for hours, a refresh token that never expires, a static (un-rotated) refresh token, rotation with no reuse detection, a refresh token in localStorage, no revocation on logout or breach, or an over-broad scope that no audience restricts. You are scored on catch rate against false positives — because flagging a sound setup (a secure-enclave mobile store, a refresh-less service, a long-but-bounded remember-me) is its own failure. Clear the queue clean.
The real job. More noise, a tighter clock.
Token-handling queue
Call each OAuth / OIDC token setup: sound, or name the single lifecycle defect.
#1
first-party SPA
context: Customer dashboard — browser single-page app
#2
SPA, long access token
context: Internal admin console — browser SPA
#3
mobile, eternal refresh
context: Consumer mobile app
#4
SPA, static refresh
context: Marketing portal — browser SPA
#5
SPA, localStorage refresh
context: Analytics dashboard — browser SPA
#6
logout = client-side only
context: Employee web app — server-rendered
#7
read-only widget, god scope
context: Embeddable read-only status widget
#8
BFF, refresh stays server-side
context: Web app via a backend-for-frontend; browser only holds an httpOnly session cookie
#9
rotation, silent on replay
context: Customer portal — browser SPA
#10
mobile, secure enclave
context: Banking mobile app — long-lived login expected
#11
token good at any API
context: App that calls the billing API, but the token is accepted by payroll and HR APIs too
#12
confidential, 8h access
context: Internal reporting app; access tokens are stateless JWTs with no introspection
#13
service-to-service
context: Backend batch job calling an internal API with its own client credentials
#14
no breach kill-switch
context: Healthcare records app; a stolen-laptop breach was just reported
Catch rate vs. false positives
Call each setup, then grade. So far 0/14 decided, 0/10 defects caught, 0 false positive(s).
How it is scored
Catch rate = broken configs given the exact right finding.
A false positive (flagging a sound config) takes an extra hygiene bite — an alert queue that cries wolf is as useless as one that misses.
Harder tiers add subtler setups and deliberate traps (secure-enclave mobile stores, refresh-less services, short stateless JWTs, long-but-bounded remember-me).
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based token-lifecycle lab: work a queue of ~20 OAuth 2.0 / OIDC token setups and call each one sound or name its single lifecycle defect.
- Defects seeded across the queue: access-token lifetime too long, refresh token with no absolute expiry, no refresh-token rotation, rotation without reuse detection (no family revoke), refresh token in XSS-reachable storage, no server-side revocation on logout or breach, and over-broad scope with no audience restriction.
- You are graded on catch rate weighed against false positives — flagging a sound config takes an extra hygiene penalty, because an alert queue that cries wolf is as useless as one that misses.
- Difficulty tiers add subtler setups and deliberate traps: a secure-enclave mobile store, a client-credentials service that issues no refresh token on purpose, a short-lived stateless JWT with no revocation endpoint, and a long-but-bounded remember-me refresh.
- The security content follows the real standards — RFC 6749, RFC 9700 (OAuth 2.0 Security BCP), RFC 7009 (revocation) and RFC 8707 (resource indicators) — and after grading every setup shows why the right call is right.
Frequently asked questions
What is the Token Lifecycle Lab?
A free, in-browser exercise where you work a queue of OAuth 2.0 / OIDC token-handling configurations — client type, access- and refresh-token lifetimes, refresh-token rotation, reuse detection, where the refresh token is stored, revocation on logout and breach, and the granted scope and audience — and give each one a verdict: sound, or the specific lifecycle defect. You are scored on how many real defects you catch with the exact right finding versus how many sound configs you wrongly flag.
What token-lifecycle decisions does it teach?
The real ones: access tokens should be short-lived (minutes) because they usually cannot be revoked individually, while refresh tokens are longer-lived but must have a hard absolute cap; public-client refresh tokens must rotate on every use, and a replayed rotated token signals theft and must revoke the whole token family; refresh tokens must never sit in localStorage or a non-httpOnly cookie where XSS can read them; logout and breach response must revoke tokens server-side, not just client-side; and tokens should carry least-privilege scope bound to a single audience/resource so one leaked token is not accepted everywhere.
Does it talk to a real identity provider?
No. Nothing is uploaded, no token is minted, and there is no network or crypto call. The scenarios are authored, realistic token-handling configurations bundled with the page, each with one ground-truth verdict grounded in RFC 6749, RFC 9700, RFC 7009 and RFC 8707. It runs entirely in your browser — no account, no install, nothing sent anywhere.
Who is it for?
Platform, identity and application engineers who design auth flows, security engineers reviewing OAuth/OIDC integrations, and anyone prepping for a security or backend interview who wants to feel why a 24-hour access token, a never-expiring refresh token, rotation without reuse detection, or a refresh token in localStorage are findings — and why a secure-enclave mobile store, a refresh-less client-credentials service and a short stateless JWT are not.