(author of the paper in your second link, which the Biscuit spec also references)
Macaroons are an abstract thing. They don't define an encoding format, nor any semantics or language for the caveats. So a lot of detail is left up to the implementer, which is why they're fairly hard to use. Their basic form is also built on symemtric keys and hmacs, so only the issuer can verify, which is a significant limitation in the real world.
AFAICT Biscuits define those (protobuf for encoding, a logic language for the caveats) and use public keys instead to allow other parties than the issuer (=holder of the root key) to verify them.
That abstraction is also a strength. I think one of the reasons Macaroons really resonate with security engineers is that the underlying cryptography is simple and user-proof, and the resulting formats and protocols are super flexible†, which is not a combination you typically get with cryptosystems. It's also one of the truly great security papers; having worked with a team for a year scaling them out, I get something new every time I read it. My only quibble is the internal naming ("CID", "VID").
We're doing a big-ass blog post as we speak about how our Macaroon tokens work, and it covers how we worked around the issuer/verifier constraint (spoiler: a litefs-backed replicated isolated internal API) and we did basic stuff like encoding (spoiler: we defined a rigid struct schema, and just MsgPack'd it).
One of the things I think I have to say about Macaroons is that there's a sliding scale of how much you use it; I think there are some simple ideas in them that would be pretty neat in any application's authentication cookie scheme.
† Also one of a couple reasons, I think, that "standard Macaroons" and their associated libraries never went anywhere.
Very much looking forward to the blog post! At G we’ve relied on some existing key replication APIs and the caveats have just been the simplest possible and rigid protobufs for each application.
(And thanks! I’m still citing your Velvet Underground comparison.)
I’m very intrigued and excited about this! I read your earlier post comparing schemes and saying after years beating the drum for macaroons, after trying to implement them, you wouldn’t beat that drum any more. Have you come back around?
I'd recommend listening (or reading the transcripts) to anyone who's needs or wants to understand more about JWT and other tokens
(And if you're not, check out the other episodes still. That podcast is great, some of the episodes get really deep into the cryptography weeds but if I get trough them I still feel like I learned something :-) thanks for making it)
Tldr client-server is different than server-server, you should think about your use case and what you need from your auth system, but tptacek thought long and hard about each at two different companies and decided on macaroons in both cases. Good to know!
(Just kidding, ish, and though they're quite long they're not too long and I did read; would recommend.)
First, I don't think that's a good characterization of the talk.
Second, I'm not sure (based on the talk) that I see how they had any of the problems that Macaroons solve.
Third, I think a lot of the trouble they ran into feels like generic "we built our own token system" stuff; for instance, they backed themselves into designing a refresh token system (all their Macaroons had a third-party caveat discharged by their central Rails app, which, without any extra context, seems like a weird choice); similarly, they ran into revocation problems, which they addressed by routing all their requests through their Rails application --- these are just standard "stateless token" problems that you'd run into with a custom JWT solution as well!
(They also issued a whole bunch of long-expiry stateless tokens, and then had to wait forever to transform them to their new tokens, which is a problem every token and stateless cookie implementer has had to deal with).
I feel like they kind of went "full Macaroon", exercising all the features described in the paper, some of which weren't good fits for their problems.
We wrote a survey of auth tokens (it's linked upthread) a year or so ago, and I mentioned this talk, and I remember at the time that it made a dent with me. But we've spent a year rolling out Macaroons and gotten real-world experience with them, and in the course of writing that up I re-watched the talk and was much less persuaded by it --- in particular, I found that much of it was less a critique of Macaroons and more just a good war story about rolling out any custom stateless token scheme.
https://backstage.forgerock.com/docs/am/7/oauth2-guide/oauth...
https://research.google/pubs/macaroons-cookies-with-contextu...