Token-Based Architecture Design
summary
Token design determines whether authentication is a DB bottleneck or a constant‑time primitive: using stateless signed tokens (encrypted payload, HMAC) removes per‑request lookups, requires shared key rotation, and yields ~220 bytes (330 with scope). Revocation works by a short lifetime plus a token revocation blacklist propagated over a back channel and cached in memcache/Redis, so logout is an acceptable slow path. Pattern examples: “happy accident” HTML scraping (Billboard scraper built and used), API gateway/front desk and full service‑oriented metropolis.
AI-written summary · about
chapters (21)
- 0:00Intro
- 2:08API PHILOSOPHY
- 2:36TWO PILLARS
- 4:59COMMON API ARCHITECTURES
- 6:06THE HAPPY ACCIDENT
- 8:20THE FRONT DESK
- 9:59BEHIND THE DESK
- 10:55BUILDING A BIGGER DESK
- 11:43THE ROUTING DESK
- 13:13A FRONT DESK IN EVERY SERVER
- 14:28TOKEN DESIGN - THE OLD WAY
- 14:47TOKEN DESIGN - A BETTER WAY
- 16:16BENEFITS
- 16:35PARSING REQUIREMENTS
- 17:06PAYLOAD VALUES
- 17:53TOKEN CHARACTERISTICS
- 18:19OAUTH 2.0 EXAMPLE
- 18:29LEAVING METROPOLIS
- 18:39BEFORE YOU LEAVE
- 20:12A CITY OF HIDDEN TUNNELS
- 21:15REVIEW
related talks
46mAuth and Distributed Systems: Don't Throw the Baby Out with the Bathwater
43m10 steps to build a strong Token based API Security
27mManaging a State of Distrust
43mA Token Walks Into a SPA...
26mSecuring Single Page Applications with Token Based Authentication
38mAuthentication as a Microservice: Portable Customer Identity Management
53mDeconstructing REST Security
47mDeconstructing and Evolving REST Security