| I'd never heard of macaroons. Here is a website: http://macaroons.io/ I note that the logo depicts macarons [1], rather than macaroons [2]. A parent comment also mentions PASETO: https://paseto.io/ Sadly, a paseto does not appear to be any kind of biscuit. The PASETO site links to this searing indictment of JWTs and related things: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... I am far from qualified to evaluate any of these! [1] https://en.wikipedia.org/wiki/Macaron [2] https://en.wikipedia.org/wiki/Macaroon |
PASETO is by Paragon, the authors of said searing indictment.
IMHO their argument really comes down to a difference in opinion in how cryptography should be supplied to developers. TLS and JWT standards allow for a wide variety of cryptographic algorithms, and implementations may provide various ways to negotiate that set of algorithms, such as whitelisted set.
This provides for migration over time from legacy systems to new algorithms, but creates a risk that the library author will have a security issue in their implementation of the standard, or that the application developer will misconfigure said implementation.
The alternative strategy is something like NaCL/libsodium http://nacl.cr.yp.to, where experts standardize on single packages of algorithms (or extremely limited set, such as one standard and one legacy) to implement specific cryptographic primitives.
The problem usually quoted here is one of compatibility, migration, and experimentation. There are often no provisions for older systems which cannot handle one of the profiles involved, or primitives for managing non-standard cryptographic sets. Many of these specifications also dictate removal of an old algorithm set to add a new one - making the specification only really valid in lock-step upgraded systems.