Server_error When Requesting Access Token in Client Credentials Flow

[reza1]

Hi

I am encountering an issue while trying to request an access token using the Client Credentials grant type for my custom API. The request is failing with a server_error, and the response indicates an internal problem related to how Auth0 is handling ES modules (node-fetch) in the webtask environment.

Details of the Issue:

I am making a request to the /oauth/token endpoint with the following parameters:

• Endpoint: domain/oauth/token
• Grant Type: client_credentials
• Client ID: __
• Client Secret: <client_secret>
• Audience: __
• Scope: openid profile email offline_access

Here’s the error I receive in response:

{
    "error": "server_error",
    "error_description": "require() of ES Module /data/layers/us-west-2.amazonaws.com/bJiN2iUcR3nQndHp4xv8rjRUsuzQOM6Q_8MqFy61fUI=/node_modules/node-fetch/src/index.js from /data/io/node18-actions/fb661362-0ec7-44ae-aa5c-cf8dc8c0fc8d/webtask.js not supported.\nInstead change the require of index.js in /data/io/node18-actions/fb661362-0ec7-44ae-aa5c-cf8dc8c0fc8d/webtask.js to a dynamic import() which is available in all CommonJS modules."
}

Could you please investigate this issue and provide guidance on resolving the server_error? It seems to be related to how Auth0 handles ES modules (specifically node-fetch) in the Node.js environment. Any suggestions or fixes would be greatly appreciated.

[josh.tidwell1]

Hey!

Welcome to the Auth0 by Okta Community.

The error you are receiving looks like it is coming from a require() statement to import the node-fetch package and is most likely coming from an action you are using in your tenant. The Fetch API is supported natively, so you don’t need to require it in the action. Removing that require() statement will most likely resolve the error you are encountering.

There is another error you may run into after this one has been resolved. The scopes you are using are not available with the Client Credentials flow. The openid, email, and email scopes can only be used when an ID Token is passed back to the application, and the Client Credentials flow is only returning an Access Token. The offline_access scope is unnecessary because you can enable offline access in your tenant’s API settings. With that said, the Client Credentials flow ignores all scopes passed by the parameters and returns all scopes granted to that application. You can review another community post similar to this one here.