OPA and its derivative projects really brought the idea of decoupled authorization as a viable option. It is a very powerful tool which can be applied to many layers of the architecture - from Kubernetes Admission Controllers being based on it through to network level authorization and up the full stack.
One area that is a constrained and narrow use case is around the actual application level permissions - eg what a user can do inside of your service. Having hand-rolled this in various companies - and the inevitable rebuilds that were required as requirements change such as adding a new, product packaging updates etc - you do end up with a complex web of logic - ether in your codebase or as Rego.
For these application level permissions - where the requirements really come from the product/business rather than engineering - I always felt there could be a simpler way of defining this rules. Policies needed to be in a format a business user could understand, and enforcing them needs to be extremely responsive as checks are in the blocking path of every request - and this needs to work at large scale - all whilst making every decision auditable to tick all the regulatory and compliance needs around access controls.
To this effect we begun working on Cerbos[0] a few years ago which initially targets that one specific use case - models policy in simple YAML [1] (love it or hate it!) and takes a stateless approach meaning it is infinitely scalable with none of the headache of synchronizing information about your users or resources to the authZ layer, also critically generates that single audit log of decisions.
Disclaimer: I work on the team that builds and maintains Cerbos[2].
When we started working on Cerbos[1] the very first external bit of tooling we released was the Cerbos Playground[2] which does exactly what you say - allows you to see the requests and responses as they make changes to their policies, making it easier to test and refine their rules.
This is a great starting point to prototype and test whether a decoupled authorization system is right for your use case. Cerbos uses YAML rather than a custom DSL to try and address the fact that authorization requirements generally don't sit with developers, rather a product owner of some sorts who is going to want to be able to comprehend the logic behind the permissions model.
When it comes to Authentication and Authorization, these are both core components of a system but undifferentiated building blocks so wouldn’t recommend building them yourself.
Typically using something like Auth0, Cognito, Firebase Auth, FusionAuth, Clerk or many of the other authentication services will get you a full feature set for user management with little to no work.
On the authorization front consider a similar approach of decoupling the the component out of your codebase where the permissions logic is defined as policy rather than code. I work on Cerbos[1] which is an open-source, decoupled authorization layer for your software which does exactly this.
I could not disagree more — allowing a third party to own the most crucial data in your app (the users) is a big mistake. I’ll admit to only having experience with Firebase for third-party auth, but in my experience the drawbacks of splitting auth and user related code between two systems soon outweighs the benefits of getting up and running quickly.
Auth code is undifferentiated, but if you have experience building apps it’s also not particularly difficult. I’d recommend either picking an open source solution that you host yourself or just taking a few days to grind it out.
Whilst this is a very good approach when all your data is stored in a single datastore, as applications grow it is common to start breaking out into more optimised data stores eg you may have few relational databases, a fast lookup source and a search index. This presents a problem of enforcing authorization down into each system.
An alternate way to tackle this is to have the authorization system produce the conditions which need to be applied dynamically at request time (with all the relevant context) which can then be pushed down to each fetching layer as needed [2][3]. This gives far more flexibility in the sorts of authorization rules which can be applied to the data and doesn't tie it to a single bit of technology.
As a real world example we have an integration with Prisma[3] which maps a query plan into a Prisma query format dynamically based on the context of the user and the currently live policies[4].
ah cool, i've implemented a similar thing but baked into the app dao+authz layer (so easier to do).
I would never guess people would use row level security for this for the reasons you've outlined, rarely (?) is one database the only resource you need to authorise access to, so you will need an authz for all non-db things anyway. Always assumed row-level authz was more for data warehouse type applications where a User has a client directly connected to a database, not intermediated thru multiple levels of abstraction.
Cerbos approach logically seems to make more sense to me than the general Zanzibar inspired methods like Authzed and others. I could never wrap my head around how they could authorise access (Pre and Post filtering?) to data without pushing down conditions to join with into the store. Actually having a 3rd party system like Cerbos be able to push down conditions and have good ergonomics is another thing, that is a tough problem.
This is a really neat and innovative idea. Just burned about an hour going through your website and watching the YouTube demo.
One piece of feedback I have -- I wasn't entirely sure what I was looking at from the homepage, there's a lot going on messaging and content-wise and I had to watch the video to get it.
Maybe something more to the point like "Takes policies, converts them to adapter-specific filter conditions that you tack on to your queries" might be helpful
Certainly agree and we have seen a lot of cases of JWT tokens getting bloated with more and more authorization data.
Using JWTs to hold the autheNtication information is a standard now but consuming that and applying fine-grained access controls for authoriZation using that context with a system that can enforce policies is that next step.
Having a dedicated AuthZ system in place that sits after the AuthN layer should put your mind at rest as a good one will provide a central point for all authZ logic which can be managed, tested and audited for every action within a system.
This is a very common question we get. OAuth is great for when the permissions can be modelled as a set of roles/scopes which apply uniformity. Where that breaks down as described in the article is when there needs to be more context involved in the authoriZation - beyond simple roles from your chosen autheNtication provider.
The fact that OAuth isnt mentioned a single time in the article is glaring. You should at least have a paragraph like "why not just use OAuth?" where you answer that question. Otherwise it seems youre avoiding the question on purpose, as these two items are clearly in the same space.
Thanks for the feedback - are are working on adding more comparisons of technologies onto https://cerbos.dev and will certainly make sure to include OAuth
One area that is a constrained and narrow use case is around the actual application level permissions - eg what a user can do inside of your service. Having hand-rolled this in various companies - and the inevitable rebuilds that were required as requirements change such as adding a new, product packaging updates etc - you do end up with a complex web of logic - ether in your codebase or as Rego.
For these application level permissions - where the requirements really come from the product/business rather than engineering - I always felt there could be a simpler way of defining this rules. Policies needed to be in a format a business user could understand, and enforcing them needs to be extremely responsive as checks are in the blocking path of every request - and this needs to work at large scale - all whilst making every decision auditable to tick all the regulatory and compliance needs around access controls.
To this effect we begun working on Cerbos[0] a few years ago which initially targets that one specific use case - models policy in simple YAML [1] (love it or hate it!) and takes a stateless approach meaning it is infinitely scalable with none of the headache of synchronizing information about your users or resources to the authZ layer, also critically generates that single audit log of decisions.
Disclaimer: I work on the team that builds and maintains Cerbos[2].
[0] https://github.com/cerbos/cerbos
[1] https://play.cerbos.dev/p/XhkOi82fFKk3YW60e2c806Yvm0trKEje
[2] https://cerbos.dev