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:
- Has anyone encountered an OAuth client requesting these identity-related scopes when connecting to an Auth0-protected MCP resource?
- Are there Auth0 settings or Dynamic Client Registration modes that could affect the handling of custom API scopes such as mcp:tools?
- 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?
- 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!