AI News HubLIVE
站内改写5 分钟阅读

使用AgentCore网关和MCP客户端构建安全授权码流程设置

本文演示如何在Amazon Bedrock AgentCore Gateway上为MCP服务器实现OAuth授权码流程作为入站授权机制。完成后，每个AI助手请求都将使用来自组织身份提供者的有效用户身份令牌进行身份验证。

来源AWS Machine Learning Blog作者: Swagat Kulkarni

在现代开发工作流中，开发者越来越依赖诸如Kiro集成开发环境（IDE）之类的智能编码助手来与远程工具和服务交互。然而，组织需要强大的认证机制来为这些智能编码助手和企业模型上下文协议（MCP）服务器之间提供安全的、身份验证的访问。

Amazon Bedrock AgentCore是一项完全托管的服务，帮助你在生产中部署、管理和扩展AI代理。其关键组件之一AgentCore Gateway提供了路由和保障代理与工具通信的集中入口点。当AI助手通过Gateway向MCP服务器发出请求时，该请求必须在处理前经过验证。这被称为入站认证。只有授权的用户和代理才能访问MCP服务器暴露的工具和服务。组织通常通过身份提供者（IdP）管理用户身份，例如Okta、Microsoft Entra ID或Amazon Cognito，它们对用户进行认证并颁发安全令牌来验证用户身份。

本文演示如何在Amazon Bedrock AgentCore Gateway上为MCP服务器实现OAuth授权码流程作为入站授权机制。通过本指南，你将拥有一个生产就绪的设置，其中每个AI助手请求都使用来自组织身份提供者的有效用户身份令牌进行认证。

你将学到什么

  • 授权码流程如何与作为MCP资源服务器的AgentCore Gateway配合工作。
  • 组织身份提供者的逐步配置。
  • AgentCore Gateway入站认证设置。
  • 与Kiro IDE客户端的集成。

解决方案概述

在入站授权码流程OAuth设置中，AgentCore Gateway充当MCP资源服务器，在允许AI客户端访问任何工具之前需要有效的身份令牌。

下图显示了授权码流程与AgentCore Gateway的端到端架构，包括身份提供者、AI客户端和MCP服务器的交互。

图1：授权码流程架构图。

关键组件

该解决方案涉及以下组件协同工作以完成认证流程：

  • 身份提供者（IdP）：管理用户认证并颁发令牌。上图引用了Amazon Cognito，但也可以是组织的IdP。
  • 用户：与IdP认证的最终用户，每个请求验证其身份。
  • Amazon Bedrock AgentCore Gateway：充当OAuth资源服务器，验证令牌并将请求代理到MCP服务器。
  • 智能编码助手：Kiro IDE，充当OAuth客户端并管理认证流程。
  • MCP服务器：AI助手需要访问的后端工具和服务。
  • MCP OAuth代理（可选）：帮助弥合智能编码助手、IdP和MCP服务器之间的规范标准化差距。MCP OAuth代理提供了支持授权码流程的标准化。

入站授权码流程

该流程确保AI助手发送给MCP服务器的每个请求都使用属于用户的有效身份令牌进行认证。

  1. MCP客户端连接 – 智能编码助手（例如Kiro IDE）启动到AgentCore Gateway的MCP端点的连接。
  2. 认证挑战 – Gateway检测到请求缺少有效令牌，并返回HTTP 401，其中包含指向Gateway的OAuth受保护资源元数据端点（.well-known/oauth-protected-resource）的www-authenticate头。这遵循了MCP规范的受保护资源元数据（PRM）模式。
  3. 发现 – MCP客户端从Gateway获取受保护资源元数据，其中返回IdP的授权服务器发现URL（例如https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration）。
  4. 用户重定向 – MCP客户端打开用户的系统浏览器，并重定向到IdP的授权端点，带有PKCE挑战，请求配置的作用域（例如openid profile email offline_access）。
  5. 用户认证和同意 – 用户在IdP登录页面输入凭据。IdP验证用户身份并提示同意以授权应用程序。
  6. 授权码授予 – 批准后，IdP将用户的浏览器重定向到客户端的本地回调URL（由客户端的本地监听器管理），并附带授权码。
  7. 令牌交换请求 – MCP客户端将授权码与PKCE代码验证器一起发送到IdP的令牌端点。
  8. 令牌颁发 – IdP验证授权码和PKCE验证器，然后向MCP客户端返回访问令牌（以及可选的刷新令牌）。
  9. 认证的MCP请求和验证 – MCP客户端在后续所有请求的Authorization头中包含访问令牌。Gateway验证令牌的签名、过期时间、颁发者以及受众或自定义声明，然后将请求代理到目标MCP服务器执行。

图2：授权码流程请求序列。

配置概述

下表总结了授权码流程设置中每个组件所需的配置。详细的分步说明见技术实施部分。

组件 | 所需配置 --- | --- 1 | 身份提供者 | 创建启用授权码和刷新令牌授予的OpenID Connect（OIDC）Web应用程序。 2 | AgentCore Gateway | 将入站授权设置为JWT。将发现URL配置为IdP的颁发者（例如https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration）。 3 | Kiro IDE | 在设置 > 连接器（或通过CLI）中添加Gateway URL。如果Gateway返回带有正确auth头的401未授权，客户端会自动触发OAuth流程。

技术实施

在架构和流程确定后，配置每个组件。本节提供了配置概述表中引用的三个组件的分步说明：

  • 身份提供者：注册OIDC应用程序并配置授权类型、重定向URI和令牌设置。
  • AgentCore Gateway：启用基于JWT的入站授权并指向IdP的发现端点。
  • MCP客户端（Kiro IDE）：将客户端连接到Gateway URL并验证端到端OAuth流程。

前提条件

你需要具备以下前提条件才能继续：

  • 已部署AgentCore Gateway的AWS账户。
  • 具有配置应用程序权限的身份提供者（IdP）（例如Amazon Cognito、Okta、Auth0或其他企业身份提供者）。
  • MCP OAuth代理。
  • 本地安装的Kiro IDE。
  • 对OAuth 2.0流程的基本理解。

步骤1：配置组织的身份提供者

在此步骤中，你使用组织的身份提供者注册一个OIDC应用程序，并将其配置为支持带有PKCE的授权码流程。

1.1 创建OIDC应用程序

登录IdP管理控制台并创建一个新的OIDC/OAuth 2.0应用程序集成：

  • 登录方式：OIDC。
  • 应用程序类型：Web应用程序。
  • 名称：AgentCore Gateway客户端（或你喜欢的名称）。

1.2 配置授权类型

启用以下授权类型：

  • 授权码。
  • 刷新令牌。

1.3 设置重定向URI

添加AI客户端将使用的回调URL：

http://localhost:PORT/callback

将PORT替换为客户端使用的端口。

1.4 配置令牌设置

在IdP应用程序设置中，执行以下操作：

  • 令牌生命周期：

- 访问令牌生命周期：1小时（推荐）。 - 刷新令牌生命周期：90天（根据安全要求调整）。 - ID令牌生命周期：1小时。

1.5 记录配置

保存以下值。它们将在Gateway配置中需要：

  • 客户端ID：在应用程序的“常规”选项卡中找到（Kiro IDE客户端配置需要）。
  • 颁发者URL：IdP的颁发者URL（例如https://{yourIdPDomain}/oauth2/default）。
  • 发现URL：IdP的OpenID Connect发现端点（例如https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration）。

对于此配置：

  • 无需客户端密钥 – 此流程使用PKCE（用于公共客户端如桌面应用程序）。Kiro IDE不需要或使用客户端密钥。
  • 客户端配置中无IdP端点 – Kiro IDE通过Gateway自动发现OAuth端点，Gateway返回发现URL。你无需在客户端中直接配置IdP URL。

步骤2：配置AgentCore Gateway

在配置了身份提供者后，下一步是将AgentCore Gateway连接到IdP，以便它可以验证传入的令牌。

2.1 设置入站授权模式

配置Gateway使用基于JWT的身份验证，并指向IdP的发现端点：

示例Gateway配置（根据部署方法调整）

aws agentcore update-gateway \ --gateway-id \ --inbound-auth-type JWT \ --jwt-discovery-url "https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration" \ --region

2.2 自定义声明验证

AgentCore Gateway基于标准OAuth 2.0声明验证JWT令牌，并支持自定义声明验证以适应不同的IdP实现。Gateway期望令牌包含：

  • 标准声明：iss（颁发者）、aud（受众）、exp（过期时间）、iat（签发时间）、client_id（客户端身份）和scopes（允许的作用域）。
  • 客户端标识：Gateway可以通过多种声明验证客户端身份，具体取决于IdP。

其他IdP可能使用不同的声明名称来表示客户端身份、作用域等（例如cid、azp、scp）。你可以在Gateway中配置自定义声明验证以匹配IdP的令牌结构：

  • 自定义声明：EQUALS（参见AgentCore Gateway：设置JWT）。
  • 示例：cid EQUALS 0oaz7147z771FZmdQ697（对于使用cid的IdP，如Okta）。

这将验证令牌是为你的特定应用程序颁发的。

注意：使用自定义声明验证时，Gateway的“允许的受众”字段可以留空。自定义声明检查提供了必要的客户端身份验证。

2.3 理解Gateway令牌验证

现在Gateway已配置了IdP的发现URL和声明规则，我们来看它如何在运行时验证传入令牌。

AgentCore Gateway设计为与用户获取OAuth令牌的方式无关。Gateway不区分通过以下方式获取的令牌：

  • 客户端凭证流程，应用程序直接进行身份验证。
  • 授权码流程，用户明确进行身份验证并授予同意。

Gateway只要求请求中呈现的OAuth令牌基于Gateway设置期间配置的参数是有效的：

  • 令牌签名：使用IdP发现URL中的公钥进行验证。
  • 令牌过期：验证令牌未过期。
  • 颁发者（iss声明）：与预期的IdP颁发者匹配。
  • 受众或自定义声明：验证令牌是为该特定Gateway或应用程序颁发的。
  • 标准OAuth声明：检查所需声明，如iat、exp等。

无论用户是通过客户端凭证流程、授权码流程还是其他OAuth授权类型获得令牌，Gateway对所有令牌一视同仁。只要令牌通过Gateway设置中配置的验证检查，请求就被授权。通过这种灵活性，你可以选择适合你的用例的身份验证流程，同时在Gateway级别保持一致的安全性。

2.4 验证Gateway配置

测试Gateway端点是否可访问并要求身份验证：

使用实际令牌测试身份验证

[为控制AI成本而截断]