Auth0 MCP authentication: known deviations
Requires a non-standard audience parameter for API JWTs, and puts API permissions in a permissions claim instead of scope.
How Auth0 deviates from the MCP authorization spec
- The authorize and token requests need a non-standard `audience` parameter — without it the access token comes back opaque rather than as an API JWT.
- With Auth for MCP, API permissions land in a `permissions` claim, not the standard `scope`/`scp` claims.
- Resource Parameter Compatibility is a tenant profile that has to be enabled before RFC 8707 `resource` works.
How to spot it without credentials
The issuer is *.auth0.com while the Protected Resource Metadata's authorization_servers points at the MCP server itself — the proxy pattern. On proxied tenants, /.well-known/oauth-authorization-server is a live upstream fetch that returns HTTP 500 error=server_error when the tenant is unreachable.
What it breaks in production
A 500 from the authorization-server metadata endpoint is an upstream Auth0 outage, not a broken MCP server — a monitor that cannot tell the two apart pages the wrong team.
Check a Auth0-backed MCP server
The free scanner runs the discovery and client-compatibility checks with no credentials, and every finding cites the spec requirement it violates:
npx mcpcomp https://your-mcp-server.example/mcp