Enterprise MCP SSO With Microsoft Entra and Agentgateway

January 26, 2026

Recommendation for securing internal enterprise MCP servers: leverage SSO (internal IdP) and apply policy at an enforcement point/MCP gateway. You don't need OAuth for internal enterprise MCP

MCP servers are cropping up all over the enterprise like weeds in a nice lawn. And just like weeds, this can cause problems. MCP servers should be secured, but how? The official spec says use OAuth, but that is not appropriate within an enterprise organization.

On a recent LinkedIn post I made the point:

Any internal enterprise MCP client / AI agent that communicates to an [remote] MCP server should be secured with enterprise SSO. If the agent is acting autonomously, then agent identity should be enforced. But that is for a different post… (check out my 5 part series on Entra Agent ID).

A lot of enterprise organizations use Microsoft Entra ID for their enterprise IdP. In this blog, we take a look at securing ALL MCP access with Entra ID SSO.

SSO has been around for a long time, so what’s the big difference here? They main thing is SSO is usually done in browser based applications. MCP clients are not usually browser applications. For example, VS code, Cursor, Claude, and other AI agents can run on a desktop, mobile, or cloud environment. A browser may be “around” but they are not always the direct interface. So for us to accomplish SSO from an MCP client to an MCP server, the MCP protocol must support it.

OIDC is based on OAuth, and we can perform OIDC logins by leveraging the MCP Authorization spec. And we can do this consistently for all agents/MCP clients regardless of what the backend MCP server is (ie, running within enterprise, hosted by a vendor, SaaS, etc). By tying to enterprise SSO we can apply policy to the MCP usage before it reaches the MCP server. Is this client allowed to access this MCP server? What tools are they allowed to see?

Agentgateway is a powerful opensource (Linux Foundation) MCP gateway that implements the MCP Authorization spec. That means we don’t have to try and re-write all MCP servers to use Entra. We can do it automatically from an MCP gateway.

Let’s look at an example configuration for Agentgateway:

mcpAuthentication:
  mode: strict
  issuer: https://sts.windows.net/${ENTRA_TENANT_ID}/
  jwks:
    url: https://login.microsoftonline.com/${ENTRA_TENANT_ID}/discovery/v2.0/keys
  audiences:
  - api://b92d6e60-86ff-4359-b971-04404fe079ec
  resourceMetadata:
    authorizationServers:
    - https://login.microsoftonline.com/${ENTRA_TENANT_ID}/v2.0    
    resource: https://ceposta-agw.ngrok.io/entra/mcp
    scopesSupported:
    - api://b92d6e60-86ff-4359-b971-04404fe079ec/mcp_access
    # - openid
    # - profile
    bearerMethodsSupported:
    - header
    - body
    - query
    resourceDocumentation: https://ceposta-agw.ngrok.io/entra/mcp/docs
    resourcePolicyUri: https://ceposta-agw.ngrok.io/entra/mcp/policies

This piece of YAML is all that’s needed to implement the MCP Authorization spec to force SSO flows to ANY MCP server hosted on the gateway.

The real detail is in how we configure Entra for this.

Digging into Entra ID for MCP SSO

To use Entra ID for this, we need to set up an Entra App Registration. This will be used to represent our Agentgateway. Can the MCP client access our Agentgateway? We want the Entra ID tokens to be scoped for this. Any other complex authorization policy can be handled with Agentgateway and potentially calling out to a ReBAC engine like OpenFGA.

This Entra stuff takes some attention to detail, so let’s follow it step by step setting up an App Registration for Agentgateway.

Step 1. Create App Registration

Click “Create Application” to begin the registration process. We won’t add any redirect URIs since this app is just used to represent the Agentgateway application, it won’t be doing any oauth flows itself. The MCP clients do that.

Step 2. App Registration Configured

Once the application registration is created, you can see things like it’s service principal / client_id (b92d6e60-86ff-4359-b971-04404fe079ec in our case). You don’t need to add any credentials to this app, but we do want to configure scopes that can be requested so that Entra can correctly configure the aud claim in any tokens it issues.

Step 3. Add Scopes

Click “Expose an API” –> “Add a Scope”:

Step 4. Configure Scope for Agentgateway access

Adding a new scope called mcp_access, leave it as Admin consent and fill in some details that would be displayed on any consent screens. To request the scope, you use the full scope name: api://b92d6e60-86ff-4359-b971-04404fe079ec/mcp_access

Step 5. (Optional - Recommended) add pre-consented Clients

Lastly, we can configure which clients are allowed to request these scopes. For example, we can add the public VS Code client (ie, it’s baked into VS code): aebc6443-996d-45c2-90f0-388ff96faa56.

Testing MCP SSO + Entra

We can run our agentgateway (see source code):

agentgateway -f ./config/agentgateway.yaml

And if we go to VS Code, we can add our new server:

Step 1. Add MCP Server

Step 2. Configure Streamable HTTP MCP Server

Step 3. Configure MCP URL

Step 4. Agree to Peform SSO Login

Step 5. Review MCP Config in `mcp.json`

Using your own MCP Clients

In VS Code (and Cursor, Claude, etc) the MCP client ID is baked in. But if you have your own MCP clients, or AI agents, or just want to configure your own OAuth clients for MCP access, you can do that in the Entra dashboard.

Step 1. Create a new App Registration (Public client is fine)

Step 2. Configure correct Redirect URIs

At this point you can use your own OAuth client_ids.

Caveat for MCP Inspector

MCP Inspector very closely follows the MCP Authorization spec, and unforunately for Entra ID this casues some issues.

For example, if we take a look at our OAuth Protected Resource Metadata (PRM):

{
  "resource": "https://ceposta-agw.ngrok.io/entra/mcp",
  "authorization_servers": [
    "https://login.microsoftonline.com/5e7d8166-7876-4755-a1a4-b476d4a344f6/v2.0"
  ],
  "scopes_supported": [
    "api://b92d6e60-86ff-4359-b971-04404fe079ec/mcp_access"
  ],
  "bearer_methods_supported": [
    "header",
    "body",
    "query"
  ],
  "resource_documentation": "https://ceposta-agw.ngrok.io/entra/mcp/docs",
  "resource_policy_uri": "https://ceposta-agw.ngrok.io/entra/mcp/policies",
  "mcp_protocol_version": "2025-06-18",
  "resource_type": "mcp-server"
}

You can see our Agentgateway correctly returns the PRM. A client should be able to automatically continue the OAuth/OIDC flow from this.

HOWEVER.

You can see the resource field gets set to "https://ceposta-agw.ngrok.io/entra/mcp",

This causes an issue in MCP inspector (not VS Code or other clients) because MCP inspector uses this field in the Authorization request. It sets the resource parameter based on this value (according to spec):

resource=https://ceposta-agw.ngrok.io/entra/mcp scope=api%3A%2F%2Fb92d6e60-86ff-4359-b971-04404fe079ec%2Fmcp_access

The problem is, this is not the correct resource in Entra. The correct resouce in entra is our api://b92d6e60-86ff-4359-b971-04404fe079ec client_id. If we configure the Agentgateway to return this in our PRM, then that breaks the rest of the OAuth flow, since that’s not the real URL for our MCP resource.

The fix here is to:

Make MCP Inspector more flexible to override the resource sent in the auth flows
Use a verified custom domain the app registration resource URI.

If you are doing this in production, you’d want to user a verified custom domain. Alternatively, in your custom MCP clients, make a way to override the resource parameter when calling tha authorize endpoint and use the real client_id like this example:

https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize? response_type=code& client_id=9beda151-9370-42f2-a2f7-17933c5c5a7c& code_challenge=BPfzTvHnOhmbZyB8aIW3sCG69vLmF_hG3aQRvl5C31s& code_challenge_method=S256& redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback%2Fdebug& state=38158e70909ff3264e129b13b3927b34dc299a7d2dea3b9ee62ca0f181e83db5& scope=api%3A%2F%2Fb92d6e60-86ff-4359-b971-04404fe079ec%2Fmcp_access& resource=api%3A%2F%2Fb92d6e60-86ff-4359-b971-04404fe079ec

Wrapping Up

The right pattern for enterprise MCP usage is to tie access to the internal IdP and SSO. All policy should be written against these user IDs (and groups, claims, etc). For more complex auth flows that require cross-identity OAuth ie, like if you need to call GitHub MCP servers, or Databricks, etc each which have their own IdP separate from enterprise IdP, then you can do that also with Agentgateway Enterprise: