Context: Currently, we use Auth0 Authorisation extension to manage RBAC. This extension provides a rule that is executed prior to any other rules in the Auth Pipeline to update the user’s app metadata with all RBAC information (groups, roles, permissions). Therefore, picking the user’s permissions to add custom claims to the access token is straightforward.
Constraint: Rules will reach the end of life on November 18, 2024. All current rules shall be migrated to Action.
Impact: Auth0 Authorization extension uses a rule to update the user’s app metadata with the RBAC information. There is no information about a possible update of this extension for using actions instead of rules. Therefore, this extension is deprecated and it will be removed from Auth0 at the end of life of the rules.
Concern: With RBAC managed with the Auth0 Authorization core, there is no reliable way to get the user’s permission in the Action Login Flow to create custom claims.
There are some solutions suggested by some posts on the community forum but none of them are suitable such as:
Using the Auth0 Management API endpoint to get the user’s permission within an action to create custom claims. This solution is not applicable in production because the Auth0 Management API for getting the user’s permissions has a low rate limit.
Putting the user’s permissions inside the user’s app metadata to make them available in an action. This solution is not suitable due to the synchronization issue between the user’s permissions set in Auth0 Authorization core and the ones set manually in the user’s app metadata. When an RBAC policy changes, this one shall be spread to all users one by one.
Request for support: Are there any solutions to get the user’s permissions in an action within an action logon flow to create custom claims for the access token in a reliable way?
Question: In the event object, onExecutePostLogin function parameter, there is an object named authorization with an array containing the roles assigned to the user. Why not add another array containing the user’s permissions associated to the user’s role?
Note: This concern is a blocking point in the migration from rules to actions.
Question #1: Can you please confirm if you have passed the audience query parameter in the login URL?
The login URL is currently handled by the authentication library used by the application according to the programming language used:
In the current test regular web application in Node.JS, @hapi/bell library is used to handle the authentication strategy and this one does not provide any ‘audience’ option for Auth0 or for other identity providers.
In the regular web application sample in Python provided in the Quickstart tab of the application on Auth0 portal. But in this sample, there is no setting option for ‘audience’ for the authlib library used in this application sample.
It seems that this audience query parameter in the login URL is quite new that’s why this one is not present in the used authentication libraries…
Using the login URL directly in a browser has different behaviour.
At the beginning, it works meaning that the returned access token contains the expected permissions. But quickly an HTTP Code 500 Internal Server Error is generated. I’m wondering if behind the scene, the process uses Auth0 Management API and I’m falling in the rate limit. Do you known what is behind this HTTP Code 500 in this context?
Question #2: can you please confirm if you have granted your Application API authorization by assigning the appropriate permissions?
Yes, the appropriate permissions are assigned to the Application API.
I have perform a test by adding audience query parameter to the login URL and I can get the user permission. But the working behaviour is not consistence. Trying to perform via this technique several login attempts drives to HTTP 500 Internal server error.
The interaction with Auth0 is done via existing libraires such as @hapi/bell libray for Node.js or authlib library for Python used in the Python application example from Auth0 platform. And none of these libraries have an audience option in their configuration.
Moreover in the current Auth0 Authentication API documentation, audience option is not part of GET authorize endpoint. Is audience option part of ADDITIONAL_PARAMETERS?