There are certainly products that have just become the goto options - Stripe for payments, Google Analytics for insights, BigQuery or Snowflake for data warehousing - and Auth0 for authentication (recently acquired by Okta) has joined that list.

Having a rock-solid solution establishing a secure identity for users is the first step in building any software. Once you know who they are, the next step is to determine what they have access to - this is where authorization comes into the picture. In a simple application, adding in-app authorization is relatively straightforward; but with complex applications comes a need to create different roles and permissions, which can become difficult to manage.

Auth0 Roles

Auth0 has the ability to attach roles and groups to users. These can be anything you want such as the ability to view or publish content.

Source:https://auth0.com/access-management

Through the addition of anAuth0 Rule, these roles can be added to the token which is returned to the application upon successful authentication and thus used for making authorization decisions. This simple role based access control (RBAC) can work great for basic resource and access patterns, but for more complex and dynamic applications a dedicated authorization system which enriches the context coming from Auth0 is required.

Going beyond Roles

If we take a scenario where the ability to update or delete a resource is only granted based on the following policy:

1. The user has the “admin” role assigned to them
2. The user has the “user” role and is the owner of the resource

The first scenario is simple to implement based purely on the roles coming back from Auth0. If the “admin” role is in the token of the user, then grant them access.

The second scenario is where things get more complex and using simple RBAC falls down. In this case, the context about the resource being accessed is required to make an authorization decision and looking purely at the roles doesn’t help - this is where attribute based access control (ABAC) and Cerbos come into play.

What ABAC Enables

Attribute-based access control grants users permissions based on certain attributes about them and the data they are trying to access. Attributes could be their title, their department, what piece of data they are trying to access, what department that data belongs to, or any other data held about the objects in the system.

Because you can check a user’s attributes against the written set of policies, giving a user one additional permission is much easier than having to assign them to a completely new role, as you would need to do with RBAC. This is simply not possible using just the roles provided by Auth0.

Example Implementation

To put this into practice, we have released a demo application whichintegrates with Auth0 and Cerbos. It is a Node application usingPassport.js to call out to Auth0 and Cerbos for the authorization. You cantry it out here and view thesource code on Github.

The logical data flow for how this is implemented is as follows:

1. User visits site and logs in with Auth0
2. Auth0 verifies the credentials and returns the user and their roles
3. App fetches the resource being accessed from the data store
4. App sends the user information and roles from Auth0 along with the resource and desired actions to the Cerbos PDP instance
5. Cerbos PDP evaluates the policies and returns an ALLOW or DENY
6. App conditionally returns based on the authorization response

The key part of this is Step #4 where the context about the user and the resource is gathered and sent to Cerbos to determine the authorization. In this stage all the attributes about the resource and the roles of the user can now be used to make a decision.

Going back to our example policy stating that a user with the user role can update and delete the resource if they are the owner, it is a simple check of if the owner ID of the resource is equal to the user’s ID.

Conclusion

Auth0 has become the goto choice for authentication in modern applications. When it comes to authorization Cerbos can be used to supercharge the existing groups and roles provided by enabling context-aware access controls without complex rules or token-bloat.