Lion Cipher Lab
Build a token introspection and revocation service from scratch (RFC 7662 + RFC 7009)
- Identity & Access Management
- Advanced
- ~60 min
- Free · no account required
Why it matters
Every OAuth 2.0 system has to answer two questions that sound trivial and are not: 'is this access token still good?' and 'how do I make a token stop working RIGHT NOW?' An access token is the credential a client sends your API to prove it's allowed in -- usually as an HTTP header `Authorization: Bearer <token>`. There are two families of token. A JWT (JSON Web Token) is SELF-CONTAINED: it carries its own signed claims, so any service can validate it OFFLINE with just the issuer's public key -- fast, no network call, and the subject of the sibling from-scratch-validator lab. The catch is…
What you'll learn
- minting OPAQUE reference tokens (random server-side strings) and knowing why they differ from self-contained JWTs
- building an RFC 7662 /introspect endpoint that returns active:true with scope/sub/exp/client_id/token_type, and a minimal {active:false} that leaks nothing
- protecting /introspect with caller authentication so it is not a token-validity oracle an attacker can abuse
- building an RFC 7009 /revoke endpoint that ALWAYS returns HTTP 200 -- even for unknown or already-revoked tokens -- so it is not a token-probing oracle
- wiring a protected resource API that calls /introspect to authorize each request, and watching a revoked token flip from accepted to rejected
- proving the whole token lifecycle end to end with curl: mint -> introspect -> use -> revoke -> introspect -> reject
- the caching/revocation-latency gap: why a cached 'active' result survives a revocation for the cache TTL, and how to bound it
- the core judgment: reference tokens + introspection (revocable, one network hop) vs local JWT validation (offline, fast, but not revocable before expiry) -- and when to choose each
Steps in this lab
- The fork in the road: reference tokens vs JWTs (and why revocation is the whole reason)
- Stand up the authorization server and mint an opaque reference token
- Build the /introspect endpoint (RFC 7662) -- exact active:true shape, minimal active:false
- Wire a protected resource API that authorizes each request via /introspect
- Build the /revoke endpoint (RFC 7009) -- ALWAYS 200, even for tokens it's never seen
- Prove the whole lifecycle with curl: mint -> introspect -> use -> revoke -> introspect -> reject
- The caching / revocation-latency gap -- and see it with your own eyes
- The judgment: introspection vs local JWT validation -- when to choose each