Has anyone seen this error

The error is:

{
	"action_name": "add-permissions-to-id-token",
	"response": {
		"error": {
			"message": "{\"error\":\"temporarily_unavailable\",\"error_description\":\"Invalid response from extension discovery URL: 403: {\\\"code\\\":403,\\\"message\\\":\\\"rejecting request with JWT token signed with untrusted key\\\",\\\"req_id\\\":\\\"1680100502924.405611\\\"}\"}",
			"name": "temporarily_unavailable",
			"stack": "temporarily_unavailable: {\"error\":\"temporarily_unavailable\",\"error_description\":\"Invalid response from extension discovery URL: 403: {\\\"code\\\":403,\\\"message\\\":\\\"rejecting request with JWT token signed with untrusted key\\\",\\\"req_id\\\":\\\"1680100502924.405611\\\"}\"}\n    at /data/_verquire/_node16/@auth0/rule-utilities/0.2.0/node_modules/rest-facade/src/Client.js:402:25\n    at Request.callback (/data/_verquire/_node16/@auth0/rule-utilities/0.2.0/node_modules/superagent/lib/node/index.js:905:3)\n    at /data/_verquire/_node16/@auth0/rule-utilities/0.2.0/node_modules/superagent/lib/node/index.js:1126:20\n    at IncomingMessage.<anonymous> (/data/_verquire/_node16/@auth0/rule-utilities/0.2.0/node_modules/superagent/lib/node/parsers/json.js:22:7)\n    at IncomingMessage.emit (node:events:539:35)\n    at IncomingMessage.emit (node:domain:537:15)\n    at endReadableNT (node:internal/streams/readable:1345:12)\n    at processTicksAndRejections (node:internal/process/task_queues:83:21)"
		},
		"stats": {
			"total_request_duration_ms": 522,
			"total_runtime_execution_duration_ms": 518,
			"runtime_processing_duration_ms": 5,
			"action_duration_ms": 513,
			"boot_duration_ms": 5,
			"network_duration_ms": 4
		}
	},
	"error": {
		"id": "invalid_argument",
		"msg": "Invalid Argument"
	},
	"started_at": "2023-03-29T14:35:02.413128322Z",
	"ended_at": "2023-03-29T14:35:02.936367880Z"
}

Hello, we are also experiencing this issue. Would be good to get some info on it as it is blocking us from moving forward.

1 Like

Hi @soon.hongooi,

Thanks for reaching out to the Auth0 Community!

I understand that you have encountered the "Invalid response from extension discovery URL: 403" error message.

I am currently looking into this and will get back to you shortly with my findings.

In the meantime, could you please try removing the “add-permissions-to-id-token” action from your Post-Login Flow to see if the error goes away?

Thanks,
Rueben

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 :frowning: . Do you need to know my tenant’s information? We’re on UK-1.

Hi @soon.hongooi,

Thank you for your response.

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.

Here are some helpful resources:

Please let me know how this goes or if you have any questions about the implementation.

Thanks,
Rueben

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.

1 Like

@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.

1 Like

Hi @rueben.tiow,

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.

Hi @nizar.boussarsar,

Thank you for your responses and my apologies for the late reply.

I am going to raise and escalate this issue with our teams internally to get further assistance.

I will follow up on this thread once I have updates.

Thanks,
Rueben

Hi @nizar.boussarsar,

Thank you for your patience.

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.

Lastly, I recommend checking out our How can I use the Management API in Actions? FAQ for more instructions.

Please let me know how this goes for you.

Thanks,
Rueben

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.