Hi Rueben, Yes it does go away if we remove the action. But we need the action to be there else our app wouldn’t work . Do you need to know my tenant’s information? We’re on UK-1.
After reviewing your Action script, I noticed you are adding user permissions to the ID Token.
Firstly, calling the Management API for every login transaction can become unscalable and hit the rate limits.
As an alternative, I recommend using Role-Based Access Control (RBAC). This way, you can enable the Add permissions to Access Token setting on your API settings and assign Roles to your users. Let me add that Roles have permissions assigned to them, so when users are assigned a Role, they inherit those permissions.
Then when decoding the access token, there will be a Permissions array claim with the user’s permissions.
Hi @rueben.tiow we do have RBAC in place with roles/permissions. The reason we’re adding Permissions into the ID token is to facilitate RBAC on our Frontend React application. For e.g. showing/hiding button and protecting routes. We thought this is the best solution for our SPA as the Access Token is meant for authorization for our backend services. Please let me know if this isn’t the right solution and I’d like to hear your thoughts on this.
We’re still getting the “Invalid response from extension discovery URL: 403” error. Any chance of this getting resolved? Thank you.
@rueben.tiow There’s several open discussions about the UK-1 beta region and people receiving 403 errors for the management api, extensions and just about every other area of the application when using this specific region. All the posts mention that they haven’t made any changes. Please could somebody raise this with an engineer at Auth0? So far all the responses from the Auth0 team have been unhelpful at resolving anybodies problem.
I am working closely with @soon.hongooi on this. We acknowledge that we are using RBAC and enabling the Add permissions to Access Token setting. We are able to get the permissions in the access token. We need these permissions to drive certain behaviour of the Frontend (e.g. show/hide buttons and pages). We also acknowledge that it is not recommended to decode the access token in the Frontend, therefore we setup a custom action which uses the Management API to retrieve the permissions and set them in the ID Token. We acknowledge the rate limit of calling the Management API, we are aware of this issue, and we think that this is not related to the HTTP 403 as this not happen for any user at any time (as rate limit is not hit). Is there a way to get this sorted out? Thanks.
After collaborating with my colleagues on this one, we concluded that the 403 error is happening because of your add-permissions-to-id-token action script as provided in your error log, more specifically, the rejecting request with JWT token signed with untrusted key error message.
After testing the script on my side, I could not reproduce the same errors and suspect that it may involve the values set in your script’s event.secrets for the domain, clientId, and clientSecret. Because of this, could you please make sure that these values are correct?
Adding on, I noticed that your tenant does not have a separate Machine-to-Machine application created that is linked to the Management API with the necessary scopes. As a good practice, we recommend creating a separate M2M app with only the necessary Management API scopes to limit the permissions of the access token in the event that a malicious actor gains access. This helps improve the security of our applications by granting only the permissions that we need.
. Do you need to know my tenant’s information? We’re on UK-1.