Hacker News new | ask | show | jobs
by Ficirdly 2315 days ago
Just not Macaroons again :(

Macaroons have many small edge cases that'll bite you when you try to use them in practice:

- there is no spec and all people re-implement the de-facto standard. If you read the whitepaper it's not what's in use.

- the de-facto implementation is full of holes, e.g. time is expressed without timezone so it's not clear if it's UTC or not.

- the implementation requires custom parser for custom binary format but the caveats in wild use (remember: there are no standard ones) still use text so it just avoids the potential benefits of encoding dates and numbers in binary.

- the highly hyped third-party macaroons are barely supported in implementations in the wild - only one level is allowed and it's not specified anywhere.

- if we're talking about third-party macaroons there is another layer of problems: no standard for caveats means your third-party service needs to be closely coupled with your own.

- immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/ma...

JWTs have many problems but compared to Macaroons it's just JSON and base64. This is available in all programming languages with no additional cost. JWTs also have actual spec that implementations can agree on. Macaroons promise you extreme power but doesn't deliver. Several of Macaroons issues could be resolved with some effort (e.g. standarization) others - like resolving cycles in third-party caveats are IMO design flaws deeply embedded in the format.

For more info from people deploying Macaroons in the wild see https://www.youtube.com/watch?v=MZFv62qz8RU

As for tptacek's recommendation this only serves as a reminder that even if a highly respected internet figure recommends you something you still need to do your own homework instead of blindly following.

3 comments

> - immature implementations, I'll just leave this here: https://github.com/nitram509/macaroons.js/blob/master/src/ma...

Wow. In case the master changes, here’s the highlighted code:

    /* XXX get some random bytes instead */
    var enc_plaintext:Buffer = new Buffer(MacaroonsConstants.MACAROON_HASH_BYTES);
    enc_plaintext.fill(0);
This library’s README should have an all cap “toy project, don’t use” up top.
> In case the master changes

That's unlikely (last commit in the project is dated Apr 22, 2017). And it's another problem with "the Macaroons ecosystem". After initial hype people discover real world issues with Macaroons and abandon their pet projects.

I agree that people need to do more research than just reading a blog post.

But we are not on the same page about Macaroons and what makes them interesting. I do not care about interoperability and standardization (I do sometimes, but not here). Apart from things like OIDC, most of the JWT usage I see is internal to projects; they're used as a utility library to do utility crypto in HTTP APIs. In those scenarios, it doesn't matter whether "your" Macaroons are the same as mine.

What's interesting about Macaroons are the underlying design.

I'm honestly surprised to hear that anyone would go into a project with something like Macaroons and expect to fit into a pre-existing ecosystem of compatible Macaroon implementations, because, as the post says, they're not widely used.

Perhaps you're just not sophisticated enough to evaluate token formats based on their intrinsic design /s