alex-olivier's comments

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].

[0] https://github.com/cerbos/cerbos

[1] https://play.cerbos.dev/p/XhkOi82fFKk3YW60e2c806Yvm0trKEje

[2] https://cerbos.dev

tldr

(Disclaimer: I work for Cerbos[1])

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.

[1] https://cerbos.dev [2] https://play.cerbos.dev

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.

[1] https://cerbos.dev

Not the only permissions issue at GitHub

https://cerbos.dev/blog/githubs-inconsistent-access-control

Disclaimer: I work for Cerbos[0].

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].

[0]: https://cerbos.dev

[1]: https://cerbos.dev/blog/filtering-data-using-authorization-l...

[2]: https://docs.cerbos.dev/cerbos/latest/api/index.html#resourc...

[3]: https://prisma.io/

[4]: https://youtu.be/lqiGj02WVqo?t=3601

(I lead product at Cerbos[1])

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.

[1] https://cerbos.dev

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

We are working through the priority list of SDKs. You can find them all on https://github.com/cerbos/

Node, Java and Go are already available and other languages are coming very soon.

Author of the article here.

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.

What help do you need? It's free and open source - https://cerbos.dev/

Disclaimer: I am Product Lead @ Cerbos[0] - an open-source authorization service

This article is a great summary of exactly why this area is rife for innovation and we love seeing different approaches to solve the headache of authz. Coincidentally I have just published a write up of why authorization has been so hard from a Product Management and requirements perspective. https://alexolivier.me/posts/the-never-ending-product-requir...

With Cerbos we have taken the approach of having an opinion of how things should be done to help start building out policies. One area particularly with other solutions is that you can do anything with them which is great but with authorization there a few themes that come up time and time again - application permissions, product packaging, enterprise readiness and multi-tenancy.

By giving you a structure and an open-source[1] service to run in your own stack that can work with anything that can make an http/grpc call we hope to simplify the whole system.

[0] https://cerbos.dev [1] https://github.com/cerbos/cerbos

Thank you! Every bit of feedback is appreciated

Having wasted a couple of engineers time a year on building and managing permissioning systems, the challenge and complexity really rings true

This is especially painful in B2B businesses where your customers have their own set of requirements and access controls (this department can do X, but these 3 people also have access to these other 2 departments etc). The hidden cost of supporting this plus the audit overhead really stacks up [1]

Not being one for building the same system over and over, we are now working on an open-source, self-hosted access control service - https://cerbos.dev

[1] https://cerbos.dev/blog/the-hidden-costs-of-user-authorizati...

RBAC can get you a long way, but there comes a time when you need even more granular permissions that are context aware (eg is the user an owner of the thing they are accessing and are they accessing from an internal IP address)

https://cerbos.dev/blog/the-case-for-granular-permissions

I hear you! Ended up building such a system so many times, so much we've built an open-source, self-hosted system to do it out of the box! https://cerbos.dev

Would love your feedback!

...and by that I mean authorization is the next big challenge especially in a multi-tenant/multi-enterprise SaaS type platform

I tend to fall in the trap of once you have authenticated the person and passing tokens around that can hold claims/role for authorization, you will eventually reach the point where the tokens are getting so bloated due to the complexity of access controls.

AuthN is the next big challenge especially in a multi-tenant/multi-enterprise SaaS type platform

https://cerbos.dev/blog/the-hidden-costs-of-user-authorizati...

yes!

The 'official' method is programmatically DIY!

https://cloud.google.com/billing/docs/how-to/notify#cap_disa...