It's the nature of a grab-bag metastandard that it can be twisted into a poor version of any related standard. That's the problem with standards like these.
Do you think that Macaroons are a sane alternative to JWTs? or in general, any comments on using them for authorization instead of OAuth2 or any of the alternatives?
Edit: I think I do understand that some of the problems with JWT is that they have a lot of moving parts so the attack surface is much greater as well as not helping the developer avoid getting shot in the foot.
Macaroons by comparison seem much simpler to my untrained eye, in that they are "just" a chain of HMACs, so that any modification of the different sections of a Macaroon would render it invalid.
So why would Macaroons be or not be a suitable alternative to JWTs or other auth methods?
Macaroons and JWTs are two fairly different things. JWTs are a combination of two things: 1. A standard encoding for authenticated JSON objects, and 2. a fairly ad-hoc standard set of field names.
I say ad-hoc because it's pretty much up to you what you actually put e.g. in iss, sub, jti, etc., and most of them are optional. So applications of JWTs still have to make those decisions (e.g.: If you want to convey that a JWT is issued by a particular key, do you (a) put the hash of the key as the "kid" in the header, (b) put the hash of the key as the "iss" claim, or (c) neither or both. The answer seems to be whatever you want.)
So at the same time, JWTs tie your hands by deciding encodings and identifiers for you (e.g. bytestring valued claims must be base64 encoded into strings, which then gets base64 encoded again for signing (!), keys should be JWKs, ...), but also don't actually make the important decisions for you.
Macaroons (as described in the paper) are more abstract. There is no standard encoding, or registry of hash algorithms. And indeed there is no standard language for caveats (aka claims), since that is entirely application specific. So.. macaroons make no decisions for you at all.
The main point of macaroons is delegation: If you want to pass some authority to someone and let them pass on a subset of that authority to someone else, Macaroons do that well. JWTs don't.
As a consumer/verifier of macaroons, they allow you (through third-party caveats) to defer some authorization decisions to someone else. JWTs don't.
If you just want to protect the integrity of a cookie, or an OAuth token, and nobody but you, the issuer, should touch it, then you just have to sign it - so macaroons and JWTs will both do fine. JWTs have the advantage of fixing some of the details for you.
If I understand correctly Macaroons would be very suitable for example, to build a framework for a Single-Sign On service, such that an Auth Server mints the Macaroons depending on certain access policies and then whatever services need to be secured behind the SSO can implement a verifier that consults the Auth Server for the access policy and then grant or restrict access to a request with an attached Macaroon.
Then if I decide to delegate access to someone else (or e.g. to myself in another device), I can attenuate it according to some specified parameters (by time, by allowed operations or access, by device, etc) and then send it over. Then whoever I delegated access to could in turn do certain restricted requests to the services behind the SSO without even going to the auth server to get an access token again (as long as the attenuated Macaroon is valid).
Is this correct?
Since I discovered Macaroons I've been wanting to fiure out how well would they fit to build an auth server to restrict access to an API by user roles, requested instance or even API routes for example. This way implementing things like "Share" links should be easier/safer as well as hierarchical access to an API (i.e. if I can access route X I can also access routes below X, or not, etc).
Off topic: And THIS is why I absolutely love Hacker News. After asking something I got a response from both an author of the paper and the author of the blog post where I found said paper. This community is just amazing! :)
Yes. While SSO is best implemented with a 3rd party caveat, you can also do it with simple delegation: The final verifier, i.e. the server that controls access to the resource, mints the initial macaroon and gives to the auth server. The auth server hands out time-limited attentuations of that to authenticated clients (who can further attenuate and hand to others).
The downside is that the auth server has full unlimited access to the resource, so compromising that "master" macaroon would be catastrophic. With 3rd party caveats, the resource owner can make a pact with the auth service (or multiple ones) such that a sign-off from an auth service is needed, but not sufficient, to access the resource.
> Since I discovered Macaroons I've been wanting to fiure out how well would they fit to build an auth server to restrict access to an API by user roles, requested instance or even API routes for example
Ultimately this boils down to defining a caveat language to describe these policies and building an evaluator for it. The paper has some guidelines for writing evaluators, but the gist of it is: Verify the integrity first. Make sure evaluation of each caveat can only ever restrict what's already allowed, and never escalate.
You can do everything on the client side and you don't have to mess with OAuth.
Edit: Sorry if I came across as dismissive of your article somehow.
What I meant to say is that some comment from a security expert, specifically on the Macaroons concept/implementation would be great, because to my untrained eye it looks very nice and secure but then again, I'm not an expert and thus can't trust myself on that.
For example this piece of code (fragment taken from ), restricts the Macaroon usage to given account... Or does it?
M.add_first_party_caveat('account = 3735928559')
As far as I can see Macaroons have interesting ability to be adjusted by intermediaries to limit their scope. Say you have Macaroon that gives access to your Gmail account you can "attenuate" it to limit scope only for emails in the next 10 minutes without contacting third party. That'd be very useful for OAuth like flows...