3 ms·

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 co

by jiofih 7y ago

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?

tptacek 7y ago
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.
- jiofih 7y ago
  > 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?
  - arnarbi 7y ago
    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.
    - jiofih 7y ago
      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.
      - arnarbi 7y ago
        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.

by jiofih 7y ago

tptacek 7y ago

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.

jiofih 7y ago
> 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?
- arnarbi 7y ago
  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.
  - jiofih 7y ago
    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.
    - arnarbi 7y ago
      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.