| It's actually a pretty great question! As others have mentioned, authorization often requires both a single method to authorize "can the user perform this action on this resource" as well as more flexible versions like "what are all the resources this user can perform this action on". That's one part of why authorization is hard, I wrote an article on this a little while ago [1]. At Oso (disclaimer: I'm the CTO), we solve this by turning authorization logic into SQL [2]. Supporting those APIs in a generic service definitely turns up the difficulty level -- you no longer have a single database to query. The thing is, if you have multiple services, you might already be in that situation. If I need to query another service to ,e.g., find what projects a user belongs to, and then need to go combine that with data in my database, I'm going to need to start worrying about how to do that efficiently. In those situations starting to centralize that data + logic starts making sense -- we talk about this in [3]. So now there's a bunch of companies with different takes on how to best solve this, including Oso. --- I feel bad about self-promoting so many links here... but we're passionate about this subject so we've been writing a lot about it! [1]: https://www.osohq.com/post/why-authorization-is-hard [2]: https://www.osohq.com/post/authorization-logic-into-sql [3]: https://www.osohq.com/post/microservices-authorization-patte... |
The biggest gripe we have, is lack of support for SQLAlchemy 2.0 style queries and lack of support for DB & Python enums as role names
We had a chat with Graham who told us about your upcoming cloud offering. Looking forward to that!