We have a number of APIs that expose common services to business information.
E.g. APIs that expose customers, billing information, licenses.
Customers can of course only access their own billing information, licenses and so on. To this end, users are linked to a specific customer and stored in the backend (so, not available in Auth0).
On top of these APIs, some vertical applications are built (most of them being SPAs + backend API). These vertical applications have - of course - their own permissions.
Users of these applications are stored - as mentioned earlier - in the business backend service.
When a user logs in to such a vertical application, the access token should contain permissions both for the vertical application and for the backend services.
Some permissions of the user will depend on licenses (which can be retrieved through a business backend service), and hence, the permissions in the access_token will be dynamic.
What would be the best approach to handle this in Auth0?
Things I have considered:
Create Auth0 APIs for the business APIs and create a client for the vertical applications.
Use the Auth0 Authorization Extension to define permissions and roles for each vertical application.
It looks like this could work, but how can I get to the users (which live in the backend business API) and how can I dynamically add scopes depending on the license the user holds (which can retrieved from the backend business API)?
If users login through the Auth0 service then they will need to be surfaced at Auth0; you can still maintain all or most of the information about each user in your backend, but they will exist also at the service so you establish a way to link the user identity to the associated business information. For example, by storing an internal business identifier as part of app_metadata which would then allow to query your system upon each end-user authentication.
In particular, you could have a custom rule that queries your system for the information required to reflect the accurate permission set for the end-user in the issued access token.
Another thing to have in mind is that permissions you include at the access token won’t change for the lifetime of the token so you may want to consider the level of detail in the permissions you place there. It’s perfectly fine to exclude very volatile permissions from the access tokens and instead choose to do those checks later at the API level; for example, an access tokens includes a generic permission read:projects, but the API then also makes sure that the end-user only reads the projects that he created.
In summary, you can dynamically add scopes through custom rules and you can either choose to query the information that allows you to do that at each authentication transaction or move it to Auth0; authorization extension or application metadata.