Skip to content

← Back to top all-time

nitram509

macaroons.js

HTML2015–2020

nitram509 / macaroons.js

macaroons.js

Javascript implementation of Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud.

Web Development Security & Privacy DevOps & Cloud Libraries & SDKs

Explore on GitHub Read Hacker News discussions

7Distinct people

9Mentions

0Explicit recommenders

80GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Javascript implementation of Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year9 dated mentions

Observed mentions: 2015-05-28 13:20:15 UTC to 2020-04-02 00:09:22 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	0	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	2	0	2
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	3	0	3
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	3	0	3

What Hacker News says

3 sources

Boulth·Aug 30, 2018

I wouldn't recommend Macaroons so lightly. I spent 2 months researching them for internal use, reimplemening them from the paper and comparing with existing implementations. There are numerous practical issues with Macaroons: the caveat format is not standardized (both binary and allowed claim types), that matters a lot when using third party caveats. There are some de facto formats but they are full of issues (e.g. date format not exactly ISO). Validation of a set of Macaroons requires walking a graph, that needs cycle detection, implementations that I've checked do not allow nested third party caveats, that invalidates one reason to use them. Attenuation is nice but it doesn't play nice with third party caveats (hash is used as a key for decryption, appending to a third party caveat changes hash). Then there are implementation errors su

Read the rest

ch as: https://github.com/nitram509/macaroons.js/blob/master/lib/Cr... Some of these issues could be removed by slightly changing implementations but the de facto implementation basically froze it. (then there is a fact that the de facto impl already changed some aspects from the paper, e.g. calculation of hash for appended third party caveat).

In Why JWTs Suck as Session Tokens (2017)

Boulth·Aug 30, 2018

Because they have a lot of complexity that, for a code they runs a part of auth logic, is really dangerous. For example, verification of third party Macaroons requires building a directed graph, that needs cycle detection. No implementation that I've checked does this instead allowing only one level of nesting. Third party caveats have more problems, if a third party would issue them they need to be standardized but there is no such standard. Worse, even the underlying byte format is not standardized instead there is this de facto standard of using "variable op value" format. But what variables are supported? It needs to be specified or the third party macaroon would be invalid. If we talk about byte formats Macaroons are serialized using another custom format. Compare this with base64 and JSON used by JWT. Then there are certain "program

Read the rest

ming shortcuts" in implementations [0]. I've spent some time implementing Javascript library to build and verify Macaroons from the paper (that is also inconsistent with the de facto implementations) but ultimately I've decided to just use limited subset of JWT. It's just simpler. [0]: https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...

In Approaching Access Control on the Web (Part I)

Shoothe·Jan 5, 2018

Macaroons have many moving pieces, caveats being just one of them. Standardization would have to approach it from all edges. For example the binary format while simple is also "de facto" standard resembling protobuf but not exactly. Maybe CBOR would be a good idea (or a subset of it)? As for caveats there are two forces at place: some want simple format ("X op Y") but there is another way that I've explored in a PoC - use simple stack-based script system (similar to Bitcoin Script [0]), then you can encode some really interesting properties inside your tokens (like requiring hashes of different properties, or signatures) so it would be kind of a meta-authorization scheme where you can delay the decision (e.g. require EC signatures for some sensitive operations). Of course this brings additional complexity but on the other hand using cavea

Read the rest

ts in "X op Y" form doesn't bring any benefits over JWT claims. [0]: https://en.bitcoin.it/wiki/Script The ultimate reason why I abandoned Macaroons (after working for some prototypes and creating a JS library for them) is just the amount of complexity needed to work with them. And remember - code working with Macaroons is being executed before the request is authorized (that's what they are for) so this code need to be carefully audited and any bug can have severe consequences. Compare that with JWT, you can write a verifier in simple code (JSON and base64 are built-in in any language) and simple is easier to audit. In Macaroons you first need to decode base64, parse custom binary format, check consistency (no cycles in third-party caveats), decrypt third-party keys. Moreover there can be multiple Macaroons for given ID, you need to check if at least one satisfies the request. Better - check all of them and then see if at least one works (to protect against side-channel attacks). So there is some inherent complexity in the entire stack. Removing it would require some substantial work. IMHO that's why they are not widely used. Oh, did I mention the existing libraries have some rather significant issues [1]? [1]: https://github.com/nitram509/macaroons.js/blob/master/src/ma... So to answer your question: I would gladly see some standarization effort, but it needs to be really thorough to have good effect. Unfortunately Macaroons are already plagued by old cruft (e.g. third-party caveats ID are called "cid" and first party caveats are also called "cid" but they are completely different) that no-one wants to touch not to break existing code. If you don't mind we can keep the discussion here, it's good for others to see (I got into Macaroons because of one of these threads) and it's google-able :)

In Show HN: PAST, a secure alternative to JWT