Macaroons Escalated Quickly
Macaroons—cryptographic, caveat-bearing tokens used for authorization—are being explored as a flexible alternative to traditional cookies and JWTs, with particular appeal for delegation and fine-grained access control in distributed systems. Commenters examine tradeoffs between symmetric HMAC-based macaroons and asymmetric schemes like Biscuits or JWTs, touching on performance, key management, revocation, and the operational cost of central verification. Along the way, readers note the persistent confusion between “macarons” and “macaroons” in naming and imagery, highlighting how even terminology can complicate the adoption of new security mechanisms.
Macaron vs. Macaroon (and Other Linguistic Tangents)
- Large subthread on the difference between macarons (French meringue “sandwich” cookies) and macaroons (coconut drops).
- Several point out the blog image shows macarons while the token scheme is named “macaroons”; some treat “French macaroon” as an acceptable synonym, others insist this is just wrong.
- Discussion broadens into language drift: entrée meaning “main course” in American English, “mains” in UK menus, “macarrons/macaroni/maccheroni” as pasta, and jokes about “Macron/micron/mâcon/maçon”.
- Some see the naming confusion as whimsical marketing; others think picking “macaroon” despite existing confusion was a poor choice.
Macaroons as Auth Tokens: Design, Tradeoffs, and Comparisons
- Multiple comments restate macaroons as bearer tokens that can be attenuated and delegated without contacting the issuer, often compared loosely to a “chain” but explicitly not a blockchain.
- Capability-based model is emphasized: authority flows from possession of a token, not from identities; this is seen as a feature, but complicates authenticated delegation and auditing.
- Concerns raised: single symmetric root key, key rotation, need for online verification, revocation, rate limiting, and difficulty of centralized auditing of derived tokens.
- The article’s deployment uses a verifier service acting like a software HSM; this is presented as mitigating symmetric-key risks and making biscuits (public-key-based) less compelling here.
- Comparisons with Biscuits, UCAN, JWT, Zanzibar, and “runes”: macaroons win on simplicity, speed, and post-quantum-friendliness; biscuits and similar systems win on offline verification and richer policy logic.
- Some argue attenuation/delegation should be more widely used; others say macaroons are overkill for simple CRUD apps.
Implementation Details, UX, and Documentation
- Clarifications that blog Python is pseudocode; real system uses typed formats, AEAD, Noise/mTLS-like channels, and strict caveat handling.
- Readers ask for clearer signaling of “toy” vs “production” code and more background on HMAC, attenuation, and prior posts.
- Some praise the writing and illustrations; others find the tone occasionally “inside baseball.”
- Side discussion on Fly.io DX: confusion over database machines, credentials, and environment-variable access, linked to a deliberate security model that treats secrets as “hazmat.”
Patents and Legal Concerns
- A Google patent on macaroons is noted; some avoided the tech due to fear of infringement.
- Others point to Google’s non‑aggression pledges and general practice of “defensive patents,” but it’s unclear how binding such pledges are in court.