Really great overview of API token security which points towards a macaroons based approach.
The last several weeks of my life have been about API security. I’m working on a new permissions system for Fly.io, and did a bunch of research into my options. We even recorded a podcast about it. I won’t leave you hanging and tell you right up front: we’re working on rolling out a Macaroon-based scheme, which you’ll read more about later.
Biscuits (the last ones described in the post) are interesting in a way
The way I see it, for distributed applications, macaroons are problematic, because to figure out whether a user has access to something, you need to understand all caveats involved.
That’s not the case with UCANs because they’re constructive: If you don’t understand some capability in the UCAN, you don’t care about it anyway, so you can safely ignore it.
With Biscuits you still have caveats, but they’re trying to figure out the format for caveats, their solution seems to be “Datalog defined caveats”. Now anyone understanding datalog will understand any caveat.
At least that seems like the idea. However, they’re still not constructive, so I figure you’d get bitten by not agreeing on what the environment is under which the datalog queries are defined, or even something more banal like the datalog version.
The problem with this as I see it is that they’ve embedded the need to interpreting / running datalog statements into the token parsing code and that’s just way to high in the stack for that, eg lots of biscuits won’t have any real meaning unless some datalog code is run. Using paths / uris is much more in line with how the web works and has much more widespread support and better related DX.
