libmacaroons

I wonder why macaroons [1] are not even mentioned in this discussion yet. They have all the upsides of cookies, but also can be narrowed down to be handed to third parties (good for APIs), caveats, and have a standardized and implemented [2] verification scheme. I wonder why they don't see wider use. Do they have significant downsides? [1]: http://hackingdistributed.com/2014/05/16/macaroons-are-bette... [2]: https://github.com/rescrv/libmacaroons

If you're like me and are wondering what Macaroons are, some searching revealed to me that this is the 2014 paper [1] that introduced them to the public. It's a nested, chained HMAC construction that's useful for delegation, and here's a library and some code examples [2] that one can play with to get a feel for what they do and how. No wonder it's not well known: it hasn't been picked up by the blog treadmill where dudes on Medium post half-baked info they just found out about, and isn't being pushed by commercial auth proxies. On that note, posts by Latacora or affiliated persons, there and here, seem to mix well-researched opinions and advice with in-jokes that are lost on all but other experts, assumptions of an inconsistent amount of domain expertise, and quips that muddy some topics more than a bystander would reasonably expect. Why

> - No built in mechanism to support key rotation (like JWT header kid). You'll need to roll your own. That's not true. Macaroons have identifier field. See the Readme doc in libmacaroons [0]. Direct quote: > The public portion tells us which secret we used to create the macaroon, but doesn't give anyone else a clue as to the contents of the secret. [0]: https://github.com/rescrv/libmacaroons/blob/master/README I'd say that the biggest difference between JWT and Macaroons is that Macaroons are on one hand simpler than JWT (only one algorithm allowed) and on the other a lot more flexible. Caveats are just byte arrays and it's up to the user to decide how to verify them. The official docs present simple case of string predicates (user = Alice) but it'd be also possible to use something similar to Bitcoin Script. Of course this flexibility h

Depending on your situation, you've got only 3 reliable options, as far as I'm concerned. 1. You could just generate random session IDs (UUIDs or 128-bit base64 strings) and store them in your database or in a persistent cache like Redis. Most OAuth middleware offer this functionality already. Drawback: Scalability - but in most cases you don't need it. 2. Use an alternative format that doesn't provide all the features of JWT, but provides better security: Fernet or Macaroons. https://github.com/fernet/spec/blob/master/Spec.md https://github.com/rescrv/libmacaroons You'll need to implement claim validation and expiry validation all by yourself. Fernet is probably better for you if you don't need the killer feature of macaroon (stacking caveats). The payload can be anything, but if you really like JWT you can always stick a JSON-encoded JW

You say that the standard is bad and that indirectly caused bugs in JWT implementations but looking at Macaroons examples there are still some corner cases where a programmer can make mistakes. For example this piece of code (fragment taken from [0]), restricts the Macaroon usage to given account... Or does it? M.add_first_party_caveat('account = 3735928559') Only someone familiar with the topic will notice that it doesn't add anything to M as Macaroons are immutable but instead returns a new, adjusted object (the same "issue" happens in Java with BigIntegers). If you know what you are doing you won't make this mistake but in this case you would also have safe JWTs... 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 accoun

I don't think performance is the issue. A heavy static file serving workload (like a CDN) is either I/O bound or memory bound, depending on whether data set can fit in cache and the network situation. The HMAC verification is just doing MD5/SHA1 hashes and comparing for equality, which all CPU (and really CPU, not CPU + memory, since the data is so small). It's tens of microseconds of CPU implemented in JavaScript (Table II). I'm sure it will be single digit microseconds or less implemented in C, so that's at least 100K - 1M req/s. The CPU will be negligible compared to the rest of the workload. The performance issues with naive solutions for auth of static files are pretty different: hitting databases for auth checks, copying data through two process, context switches, etc. Those are things likely to slow down a static file serving

Code here: https://github.com/rescrv/libmacaroons