Auth0 + Grok MCP: invalid OAuth scopes and repeated Dynamic Client Registration

Get Help
1

Hi everyone,

We’re troubleshooting OAuth authorization between a Grok.com custom MCP connector and an Auth0-protected MCP server.

What we’ve confirmed:

  • Our MCP server publishes OAuth Protected Resource Metadata, including scopes_supported: [“mcp:tools”] and Auth0 as the authorization server.
  • Auth0 Developer Support observed a Grok /authorize request containing scopes such as name, given_name, nickname, picture, created_at, and identities, which Auth0 reported as invalid.
  • The logged scope parameter was truncated, so we cannot confirm whether mcp:tools was also requested.
  • Reconnecting the Grok connector appears to create a new dynamically registered OAuth client each time, eventually reaching our Auth0 tenant’s application limit.
  • Our MCP server requires the mcp:tools API scope, and we do not want to weaken that security requirement.

Questions for Auth0/OAuth specialists:

  1. Has anyone encountered an OAuth client requesting these identity-related scopes when connecting to an Auth0-protected MCP resource?
  2. Are there Auth0 settings or Dynamic Client Registration modes that could affect the handling of custom API scopes such as mcp:tools?
  3. Is there a standards-compliant way to reuse an existing OAuth client registration or support a fixed Client ID, without creating new Auth0 applications on every reconnection?
  4. What is the safest way to diagnose the complete requested scopes and API audience without exposing tokens, secrets or sensitive logs?

We’ve already contacted Auth0 Developer Support and the MCP client’s support team. We’re looking for practical implementation experience or additional diagnostic insights.

Any guidance would be greatly appreciated.

Thank you!

4

Hi @hslwijnands-spec

Welcome to the Auth0 Community!

You are asking how to resolve an OAuth authorization failure between a Grok.com custom MCP connector and your Auth0-protected MCP server, where the connector requests identity-profile scopes that Auth0 rejects, the mcp:tools API scope may not be requested, and each reconnection creates a new dynamically registered application.

I understand that you are already troubleshooting this issue through a support ticket with our support engineers on the matter and have made significant progress. My personal suggestion would be to continue receiving support through the dedicated channels regarding the matter and share the causes and solutions with everybody else here if possible.

The recommended suggestions for the issue would be to Limit the connector’s requested scopes to values your API defines, request the API audience explicitly, and store the client registration returned on first connection so later reconnections reuse it.

  1. Confirm the full requested scope and audience without exposing tokens. Enable tenant logs for the failed authorization attempts and read the scope and audience parameters in each entry. Do not copy access tokens, refresh tokens, or client secrets into tickets or chat. Decode any token only in a local, trusted tool and record only the aud and scope claims.
  2. Verify that mcp:tools is defined under the Permissions tab of the Auth0 API whose Identifier is your MCP audience. The connector must request mcp:tools along with the audience. Your MCP server should continue to require this scope.
  3. Review the API settings that control whether permissions are returned in the access token, including the RBAC settings for the API. Permissions granted to a user are only included when these settings allow it.
  4. Ask the connector provider to send only the scopes listed in your protected resource metadata (mcp:tools) plus openid and offline_access if refresh tokens are needed. Profile claims should be requested through openid profile, not as individual scope names.
  5. Reuse the registration. Store the client_id and client_secret returned by the first Dynamic Client Registration call for each connector, and reuse them on every later connection. Auth0 creates a new application each time the registration endpoint is called, so repeated calls cause the application limit to be reached.
  6. Remove unused dynamically registered applications from the tenant to free capacity, after confirming with the connector provider which registrations are still in use.
  7. Consider a pre-registered client only as a temporary measure. Community responses note that a manually created application deviates from the MCP model and does not scale, so the reuse approach in step 5 is preferred.

At this time, since the issue is still being troubleshooted, I will be waiting for a final resolution and share it with everybody else on the community if possible.

Kind Regards,
Nik

5

Hi Nik,

Thank you for your warm welcome and for taking the time to provide such a detailed and helpful response. I really appreciate it!

Since posting my original question, we have made significant progress.

We now have a working OAuth authentication flow between Grok’s custom MCP connector, our isolated MCP gateway, and Auth0. Grok has successfully authenticated, connected to the MCP server, discovered its tools, and executed browser-related MCP tools.

Your recommendations have also helped us identify several areas for improvement:

  • Scopes and permissions: Our MCP gateway advertises mcp:tools, and we have now added explicit scope validation for incoming MCP requests.
  • OAuth diagnostics: We have added logging to capture the requested scopes and resource parameters without exposing tokens or secrets.
  • Dynamic Client Registration: We confirmed that our gateway currently stores client registrations in memory. We are investigating persistent storage to prevent registrations from being lost after a service restart.
  • Audience and RBAC: We will review these settings where applicable to our architecture.

One important detail is that our architecture uses an intermediary OAuth gateway. Grok authenticates against our gateway, while the gateway uses Auth0 for identity verification. This means some recommendations for direct Auth0-to-MCP integrations need to be adapted to our setup.

We are still investigating a separate issue involving browser session execution, but the core OAuth authentication flow is now working.

Thank you again for your guidance. We will continue testing and will be happy to share our final findings and solution with the community once everything is stable.