Azure / Microsoft Entra MCP authentication: known deviations
v2.0 endpoints reject RFC 8707 resource outright, and advertised api://-prefixed scopes are granted bare.
How Azure / Microsoft Entra deviates from the MCP authorization spec
- v2.0 endpoints reject the RFC 8707 `resource` parameter that the MCP spec builds audience binding on.
- Custom scopes are `api://{id}/x` upstream but arrive bare in the token's `scp` claim; OIDC scopes never appear in access-token claims at all.
- Issuer validation is effectively disabled for the `organizations`, `consumers`, and `common` multi-tenant endpoints, and for B2C.
How to spot it without credentials
scopes_supported contains api://… or Graph URIs, the challenge's scope= carries the prefixed form, and the authorize host is login.microsoftonline.* or *.b2clogin.com.
What it breaks in production
An audience-binding probe that sends `resource` gets a wrong-audience token, and any advertised-versus-granted scope comparison false-positives unless it strips the api:// prefix first.
Check a Azure / Microsoft Entra-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