Identity providers do not agree on the OAuth primitives the MCP specification builds on, and they move. Each page below documents how one provider deviates, how a credential-less scan fingerprints it, and the production failure the deviation predicts.
Requires a non-standard audience parameter for API JWTs, and puts API permissions in a permissions claim instead of scope.
v2.0 endpoints reject RFC 8707 resource outright, and advertised api://-prefixed scopes are granted bare.
Access tokens carry client_id instead of aud, so a standard audience check passes vacuously.
No JWKS path — token validation goes through introspection on every request.
Path-nested issuer and scopes that only become discoverable after first use.
Not OIDC at all: opaque tokens, no discovery, no JWKS, and scopes only in a response header.
Shorthand scopes come back as full URIs, and opaque tokens are verified via a query-string tokeninfo call.
Realms below 26.6.0 advertise Dynamic Client Registration that MCP clients cannot actually use.
The audience check is manual and off by default whenever resource is unset — which is the default.
The token audience is an opaque resource id, not the MCP server's URL.
aud is the constant “authenticated” for every user of every project — cross-server replay is structural.
The token endpoint rejects a scope parameter on the code exchange.
Opaque tokens with scopes sometimes only visible on a second, non-OIDC endpoint — plus hardcoded fallbacks.
Token metadata comes from @me instead of introspection, with scopes as a JSON array and identity in application.id.
aud is only correct when Resource Indicators are enabled in the dashboard and the client sends resource — otherwise it falls back to the client id.
Check any MCP server against these in one command: npx mcpcomp <server-url>