3 ms·
> 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
by ryukafalz 3y ago
> 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.
- skybrian 3y agoLimited-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.