使用Agentgateway为MCP服务器配置Microsoft Entra SSO
MCP服务器像漂亮草坪上的杂草一样在整个企业中拔地而起。就像杂草一样，这也会造成问题。MCP服务器应该得到保护，但如何保护呢？官方规范说 使用OAuth，但这是 在企业内部不合适 组织。
在最近的一次 LinkedIn帖子 我指出：
任何与\[远程\]MCP服务器通信的内部企业MCP客户端/AI代理都应使用企业SSO进行保护。如果代理自主行事，则应强制执行代理身份。但这是为了 不同职位…（看看我的 5部分系列 在Entra代理ID上）。
许多企业组织使用Microsoft Entra ID作为其企业IdP。在本博客中，我们将探讨如何使用Entra ID SSO保护所有MCP访问。
SSO已经存在很长时间了，那么这里有什么大的区别呢？它们的主要功能是SSO通常在基于浏览器的应用程序中完成。MCP客户端通常不是浏览器应用程序。例如，VS代码、Cursor、Claude和其他AI代理可以在桌面、移动或云环境中运行。浏览器可能“无处不在”，但它们并不总是直接的界面。因此，为了实现从MCP客户端到MCP服务器的SSO，MCP协议必须支持它。
OIDC基于OAuth，我们可以通过利用MCP授权规范来执行OIDC登录。无论后端MCP服务器是什么（即在企业内运行、由供应商托管、SaaS等），我们都可以对所有代理/MCP客户端一致地执行此操作。通过绑定到企业SSO，我们可以在MCP到达MCP服务器之前将策略应用于MCP的使用。是否允许此客户端访问此MCP服务器？他们可以看到哪些工具？
代理通道 是一个功能强大的开源（Linux基金会）MCP网关，实现了MCP授权规范。这意味着我们不必尝试重写所有MCP服务器来使用Entra。我们可以从MCP网关自动完成。
让我们看一下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 这段YAML是实现MCP授权规范所需的全部内容，以强制SSO流到网关上托管的任何MCP服务器。
真正的细节在于我们如何为此配置Entra。
深入挖掘MCP SSO的Entra ID
要使用Entra ID，我们需要设置Entra应用程序注册。这将用于表示我们的代理网关。MCP客户端可以访问我们的代理网关吗？我们希望Entra ID令牌的范围为此。任何其他复杂的授权策略都可以通过Agentgateway处理，并可能调用ReBAC引擎 比如OpenFGA.
Entra的东西需要注意细节，所以让我们一步一步地为Agentgateway设置应用程序注册。
步骤1。创建应用程序注册
点击“创建应用程序”开始注册过程。我们不会添加任何重定向URI，因为此应用程序仅用于表示Agentgateway应用程序，它本身不会执行任何oauth流。MCP客户端会这样做。
步骤2。已配置应用程序注册
创建应用程序注册后，您可以看到它的服务主体/client_id等信息(b92d6e60-86ff-4359-b971-04404fe079ec 在我们的情况下）。您不需要向此应用程序添加任何凭据，但我们确实希望配置可以请求的范围，以便Entra可以正确配置 aud 在它发行的任何代币中声明。
步骤3。添加范围
单击“公开API”-->“添加作用域”：
步骤4。配置代理网关访问的作用域
添加一个名为的新作用域 mcp_access，将其保留为管理员同意，并填写将在任何同意屏幕上显示的一些详细信息。要请求作用域，请使用完整作用域名称： api://b92d6e60-86ff-4359-b971-04404fe079ec/mcp_access
步骤5。（可选-推荐）添加预先同意的客户
最后，我们可以配置允许哪些客户端请求这些作用域。例如，我们可以添加公共VS Code客户端（即，它被烘焙到VS代码中）： aebc6443-996d-45c2-90f0-388ff96faa56.
测试MCP SSO+Entra
我们可以运行我们的agentgateway（见源代码）：
agentgateway -f ./config/agentgateway.yaml如果我们转到VS Code，我们可以添加我们的新服务器：
步骤1。添加MCP服务器
步骤2。配置流式HTTP MCP服务器
步骤3。配置MCP URL
步骤4。同意Peform SSO登录
步骤5。在中查看MCP配置 mcp.json
使用自己的MCP客户端
在VS Code（以及Cursor、Claude等）中，MCP客户端ID是内置的。但如果你有自己的MCP客户端或AI代理，或者只是想配置自己的OAuth客户端以访问MCP，你可以在Entra仪表板中完成。
步骤1。创建新的应用程序注册（公共客户端很好）
步骤2。配置正确的重定向URI
此时，您可以使用自己的OAuth客户端ID。
MCP检查员须知
MCP检查员非常严格地遵循MCP授权规范，这给Entra ID带来了一些问题。
例如，如果我们看看我们的OAuth保护资源元数据（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"
}您可以看到我们的Agentgateway正确返回了PRM。客户端应该能够从此处自动继续OAuth/OIDC流。
然而。
你可以看到 resource 字段设置为 "resource": "https://ceposta-agw.ngrok.io/entra/mcp",
这会导致MCP检查器（不是VS Code或其他客户端）出现问题，因为MCP检查器在授权请求中使用了此字段。它设置了 resource 基于此值的参数（根据规范）：
resource=https://ceposta-agw.ngrok.io/entra/mcp
scope=api%3A%2F%2Fb92d6e60-86ff-4359-b971-04404fe079ec%2Fmcp_access问题是，这不是Entra中的正确资源。entra的正确资源是我们的 api://b92d6e60-86ff-4359-b971-04404fe079ec client_id。如果我们将Agentgateway配置为在PRM中重用它，那么就会破坏OAuth流的其余部分，因为这不是我们MCP服务器的真实URL。
这里的修复是使用经过验证的URL进行我们的应用程序注册。
如果你在生产中这样做，你会考虑这样做。或者，在您的自定义MCP客户端中，制定一种方法来覆盖 resource 调用tha authorize endpoint时使用参数，并使用真实的client_id，如下例所示：
https://login.microsoftonline.com//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总结
企业MCP使用的正确模式是将访问与内部IdP和SSO联系起来。所有政策都应该针对这些用户ID（以及组、索赔等）制定。对于需要跨身份OAuth的更复杂的身份验证流，例如，如果你需要调用GitHub MCP服务器或Rancher等，每个服务器都有自己的IdP，与企业IdP分开，那么你也可以使用Agentgateway enterprise来实现：