Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Back in 2021, when I wrote the API token survey post, I had some, uh, caveats about Macaroons, and linked to a talk from a developer at Chain who had gone through the experience of deploying them. Don't get me wrong, it's still an excellent talk†, but after working on implementing them for a year or two I find it much less damning than I did at the time.

One problem Chain seemed to run into was coupling between their services. They had a fast Golang "ledger" and a slow Rails "dashboard", and found that Macaroons forced all their requests to loop through the "dashboard". This was because they'd opted to do short-lived Macaroon tokens that needed to be reissued every 5 minutes (eminently sane), and only their dashboard could generate the proper token?

Another problem they had with Macaroons: their Rails dashboard has an RBAC permissons interface. But once they've issued a Macaroon, users can't change permissions with the interface anymore. But that's a problem with all stateless tokens, not just Macaroons; in fact, Macaroons probably help here, because if you're presenting a Macaroon to the dashboard interface in the first place, the RBAC interface can just attenuate it for you and hand it back to you.

I still think this is a design that mostly makes sense only if you have a problem domain for which both attenuation and delegation make sense. Most basic CRUD apps don't have these problems, and using Macaroons would be a mistake for them.

† https://www.youtube.com/watch?v=MZFv62qz8RU

> I still think this is a design that mostly makes sense only if you have a problem domain for which both attenuation and delegation make sense.

I would argue that supporting attenuation and delegation (almost?) always makes sense. It's very common that I find myself wishing I could grant some piece of software some but not all permissions to some resources; this can be relatively straightforward when the authorization scheme supports attenuation and delegation, but is painful when it doesn't.

As you mention in the post, users often want to do things that the developer hadn't thought of - I'd argue that's still the case even for what you might say is a basic CRUD app.

(Yes, this is related to the old ACL-vs-capability-model debate.)

Now that said, I'm not saying Macaroons make sense for every use case - just that I think attenuation and delegation do.

Limited-access tokens that you can give to others are often useful, but there are other ways to do it.

If your application is a monolith with an API, you're going to have to implement all the permissions yourself anyway, right? That includes the UI for setting up the permissions and generating the cookie, the code for checking permissions, and the code for actually doing the work. Might as well keep the cookies very simple and put the permissions in the database.

Once you have plugins with their own permissions, possibly running on their own servers, it starts to make more sense.

I'm curious what your thoughts are on implementing a sane authorization system in 2024. You mentioned writing roles onto macroons but what does your policy look like? Is your surface area simple enough that it's not a concern?

I've been on various security teams with disjoint product-facing authz, internal authz and service authz policy engines / mechanisms etc. Additionally, authz gets baked into service code and product interfaces, so it's hard to change later.

The idea is that Macaroons are a low-level IAM language, designed close to the components that they pertain to, encoded directly into the tokens, and that higher-level IAM policies "compile down" into those tokens.

If you need more content, I would be keen to read a blog post on how you designed authz at Fly.io. I think it'd be a unique point of view, given your security background and ability to write well.

In the third_party_caveat code sample, I think you mean to be passing in the tag rather than the url, and the arguments at the call site are in the wrong order.

Edit: Or I guess along with the url.

You're right; I extracted that function from a gnarlier function I didn't want to use in the post (it was the same logic, but the function was so long it broke up the post too much) and wasn't careful enough in moving the code. Fixed, sort of! Thanks!

Go easy on me; I literally wrote this in IDLE.

I feel that the issue there is that their architecture was unable to fit the macaroons correctly.

Reply on news.ycombinator.com