Lion Cipher Lab
Build macaroons from scratch: bearer tokens anyone can narrow and no one can widen
- Identity & Access Management
- Advanced
- ~90 min
- Free · no account required
Why it matters
Most access tokens can only be made narrower by the server that issued them. If a service holds a powerful token and wants to hand a batch job read-only access to one folder, it has to call the issuer and ask for a new token, and many teams skip that and just hand over the powerful one. Macaroons, from a 2014 Google and Chalmers paper, flip this: anyone holding a macaroon can add a restriction (a 'caveat') to it offline, in microseconds, and the result is strictly weaker. Nobody can take a restriction off, because the signature is a chain of HMACs and removing a link would mean running HMAC…
What you'll learn
- implementing a macaroon HMAC chain (mint, attenuate, verify) in stdlib Python
- explaining why a holder can add a caveat but never remove one
- writing a caveat checker that fails closed on unknown or malformed caveats
- running a tamper matrix against your own token format and reading every result
- designing offline delegation: service to batch job to vendor, each narrower
- spotting caveat-language bugs: ignored unknowns, path traversal, timezone string compares
- building a third-party caveat, a discharge macaroon, and the binding step that stops discharge reuse
- choosing between macaroons, a JWT, and Biscuit for a real system
Steps in this lab
- What you are building, and the one idea it rests on
- Set up a working folder
- Write the library: mint, attenuate, serialize, verify
- Mint a token and watch the chain grow
- The tamper matrix: try to widen your own token
- Delegation: service, batch job, vendor, each one narrower
- Where macaroons really break: the caveat language
- Third-party caveats: make another service vouch, then bind the proof
- Macaroons vs JWT vs Biscuit
- Judgment: what macaroons do not fix, and when to reach for them