An example of using Azure B2C as an Oauth provider for an MCP server.… #617
Conversation
… Including a testing using a REST client extension to submit json-rpc calls to the sever via the HTTP SSE transport
| NameClaimType = ClaimTypes.Name, | ||
| RoleClaimType = ClaimTypes.Role, | ||
| // Azure B2C uses 'aud' claim for audience validation | ||
| ValidAudiences = new[] { azureB2CClientId }, |
There was a problem hiding this comment.
I think it's too early to demo using Azure B2C as an MCP OAuth provider since it does not support RFC 8707 which is required by the MCP spec. That's why this sample is unable to validate that the token was issued specifically for the resource URI specified in the ProtectedResourceMetadata like we do in the ProtectedMCPServer sample.
Here are the relevant parts of the MCP authorization specification that mandate that the MCP server MUST validate that the access token was intended specifically for them as the intended audience
Token Handling
MCP servers, acting in their role as an OAuth 2.1 resource server, MUST validate access tokens as described in OAuth 2.1 Section 5.2. MCP servers MUST validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2. If validation fails, servers MUST respond according to OAuth 2.1 Section 5.3 error handling requirements. Invalid or expired tokens MUST receive a HTTP 401 response.
https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#token-handling
Token Audience Binding and Validation
RFC 8707 Resource Indicators provide critical security benefits by binding tokens to their intended audiences when the Authorization Server supports the capability. To enable current and future adoption:
- MCP clients MUST include the
resourceparameter in authorization and token requests as specified in the [Resource Parameter Implementation (#resource-parameter-implementation) section- MCP servers MUST validate that tokens presented to them were specifically issued for their use
The Security Best Practices document outlines why token audience validation is crucial and why token passthrough is explicitly forbidden.
https://den.dev/blog/mcp-authorization-resource/ written by @localden provides a more in-depth explanation for why RFC 8707 is important. The tl;dr is that without the appropriate audience validation an attacker could host an MCP server with the same azureB2CClientId as your server, but with a different resource URI and trick victims to log into it. The attacker could then pass off victims' access tokens to your MCP server as their own and do whatever they want with it, and you'd have no way of knowing.
There was a problem hiding this comment.
Thanks, very informative to what we were trying to do. Since B2C probably isn't gonna update anytime soon to support this, we will have to put aside MCP replacing our semantic kernel plugins for now unless we make some other changes to our auth pipeline which isn't likely atm. I'll cancel the PR.
There was a problem hiding this comment.
MCP does not properly implement RFC 8707.
RFC 8707 explicitly states that "a client MAY indicate the protected resource... by including the resource parameter" (RFC 8707 Section 2-1). MCP therefore turns a "MAY" into a "MUST", which is a deviation. Please see this discussion for more details: modelcontextprotocol/modelcontextprotocol#1599
Entra uses the scope parameter as per OIDC guidelines.
IMO, at less than a year old, MCP should strive to support major IdP's rather than strive for major IdP's to support MCP.
…adme to eplicitly call out Azure B2C's need for an Authority (policy) even for client credentials flow.
3 participants
An example of using Azure B2C as an Oauth provider for an MCP server Including a testing using a REST client extension to submit json-rpc calls to the sever via the HTTP SSE transport
Motivation and Context
Right now there isn't, in my opinion, a concrete example of integrating Azure b2c with an MCP Server using the c# SDK. This example also provides literal examples of json-rpc tool calls.
How Has This Been Tested?
This was tested with an existing application that primarily uses semantic kernel plugins for tool calling and we are considering moving to MCP. However, B2C auth would be a must have. This proves the client credentials oauth flow using B2C.
Breaking Changes
No
Types of changes
Checklist
Additional context