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.