Currently I’m working on an .NET Core application (with SQL Server database) that serves as a management tool to connect users to sets of permissions.
The idea is that if a user tries to access one of our API’s (exposed to the Internet), his access token (which he got during authenticating at Auth) is checked, we extract his username from his claims and use that to fetch his permissions from our database. (The user’s email address defined in our Auth0 Tenant need to be defined in our database as well of course.) These permissions can then be used to determine if he is allowed access to specific endpoints.
Requirements
We don’t use Auth0 scopes. We use Auth0 for authentication only.
Ideally you want to fetch the list of permissions directly after authentication and let called API’s just check the user’s access token instead of needing to call the “Authorization API”.
The questions that keep popping up in my head:
1 Is this management tool something we should maybe not build ourselves but rather use an off-the-shelf solution? What applications come to mind then?
2 Would using Auth0 Webhooks be a good way to call our Authorization API directly after Auth0’s authentication took place, so the user’s permissions can be fetched and added to the list of claims in the token.
3 Would it be possible to modify a JWT when the user accesses on of our API’s and augment it with the permissions coming from the DB? (in order to prevent having to refetch them on subsequent requests)
You could use role based access control to assign permissions to the user for any API you have registers, and have those in the token.
You could do this in a rule. The rule could make an API call to your authorization API to get the permissions, then it can add the permissions in a custom claim. This will happen after authentication, but before the token is issued.
Modifying JWTs doesn’t really work. You can issue a new one, but because a JWT is signed, it cannot be modified while still being a verifiable JWT.
Many thanks for your answer! Of course a whole new array of questions come to mind…
Is there any reason to think of (best practice) why it would not be a good idea to keep a list of permissions (e.g. orders:read) in your access token? I understand there’s a size limit to an access token that I need to consider, but aside from that?
Is this (fetch data from external API from within a Rule for fetching list of permissions/claims) something that is done a lot or do we better consider another solution?
In a typical frontend → Custom API → backend API setup, Custom API would then extract user information (username), call external API to fetch list of permissions for this user and then use a ClientId and ClientSecret to issue a new token. Backend API then validates that token, reads permissions from it and asserts that the required one is in the list, something like that?
This is a common practice. There are some scenarios listed in the Oauth2 threat model spec that deal with permissions/scopes in the AT, it might be worth reading (cmd + f ‘permissions’), but it is very common to add the permissions for the resources the AT is intended for in the AT itself. Auth0 provides a solution specifically for the scenario you described, unless I am missing something about what you are descirbing.
I would say it is more common to use RBAC or permissions from an identity provider, but it is possible. One bottleneck you will run into with this setup is the request and response time of an external API. With every authentication you are waiting for these permissions to be provided from your API, which takes time.
In addition, you will have to manage the server/db that provides permissions.
I’m not sure I completely understand this use-case. Are you authenticating in the frontend (with a client side app like a React app), then sending the users AT to the custom API, which is requesting a machine to machine (client credentials) token for your backend API?
