What makes macaroons great? I read the whole documentation and the macaroon.js docs. It seems to be under-documented, the library last updated 3 years ago. I couldn’t really grasp how the mechanism is safe re. clients adding “self-attenuations” that would amount to a DoS on the receiving service. Is anyone using this in production?

Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already).

Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally despite their kitchen-sink design.

JWT is more popular because there are libraries for it in every language, and people don't think of tokens as a cryptographic design (or nobody would be using JWT!), they think of them as a library ecosystem. JWT is definitely the stronger library ecosystem!

This is also why I probably wouldn't ever bother recommending PASETO. If you're sophisticated enough to evaluate token formats based on their intrinsic design, then you should implement Macaroons if possible (it's almost always possible). If you're not, then you're going to use JWT.

> nothing’s stops discharge macaroons from containing embedded third-party caveats ... to consider

My understanding is that the receiving app has to contact each third party to retrieve the “discharge macaroon”. What stops someone from adding a bunch of dummy caveats to cause *N requests on the server?

No, the discharge is indicated to the verifier cryptographically. The user of a 3p-caveated macaroon has to request that discharge from the 3p before sending it to the server.

I don’t know what else to say - maybe the macaroonjs documentation is wrong? Full quote:

> nothing stops discharge macaroons from containing embedded first- or third-party caveats for the verifier to consider during verification.

So the user requests discharge tokens on his own, but the discharge tokens have to be verified by _my_ server and might contains nested third-party caveats which I’ll have to verify.

If the discharge has another 3p caveat, then generally you'd have to get that discharged also before sending it to a server.

Either way, in each deployment a server supports a set of caveats that makes sense and rejects others.

Or that's the intention of the original idea (I'm an author of the paper). I can't speak for macaroonjs specifically.

Are you sure you're protected from CSRF from older browsers? There's still plenty of IE going around on old desktops in libraries and such.

Not OP, but wrt to enterprise apps, SameSite protects from CSRF even on IE since June 2018 update. https://caniuse.com/#feat=same-site-cookie-attribute

Based on the user base this is a negligible minority for us, that we do not want to care about. We can simply display an error message saying that you need to use a newer version.