当您使用 Cloudflare Access 保护应用程序时,默认情况下,非浏览器客户端(例如 CLI、AI 代理、SDK 和脚本)无法完成基于浏览器的登录重定向。它们会收到 302 重定向,而没有可用的令牌或授权端点。
托管 OAuth(Managed OAuth)通过将 Access 转换为适用于您的应用程序的标准 OAuth 2.0 授权服务器来解决此问题。Access 执行与浏览器登录相同的策略,而您的源站感觉不到差异。
- 自托管 Access 应用程序、MCP 服务器应用程序或MCP 服务器门户
- 支持 RFC 8707 ↗ 的 OAuth 客户端
- 在 Cloudflare 仪表板 ↗中,转到 Zero Trust > Access controls(访问控制)> Applications(应用程序)。
- 找到您要配置的应用程序,然后选择右侧的三个点 > Edit(编辑)。
- 转到 **Advanced settings(高级设置)**选项卡并开启 Managed OAuth(托管 OAuth)。
- (可选)配置托管 OAuth 设置。
- 选择 Save(保存)。
-
获取您现有的 Access 应用程序配置:
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: Apps and Policies Read
Get an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request GET \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -
发起一个
PUT请求,并将oauth_configuration.enabled设置为true。为了避免覆盖您现有的配置,请求体应包含上一个GET请求返回的所有字段。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies Write
Update an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request PUT \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "oauth_configuration": { "enabled": true } }'
若要进行测试,请打开符合 RFC 8707 的 OAuth 客户端并向您的应用程序发起请求。该客户端应打开一个浏览器窗口,提示您登录 Access。有关更多详细信息,请参阅授权流程部分。
托管 OAuth 可在 MCP 服务器应用程序上使用,并允许 MCP 客户端使用标准的 OAuth 2.0 流程通过 Access 验证用户身份。对于与您的 Zero Trust 组织位于同一个账户中且通过 Cloudflare 提供服务的 MCP 服务器,请使用此流程。MCP 服务器必须验证在 Cf-Access-Jwt-Assertion 标头中发送的 Access JWT。
对于已经处理其自身的 OAuth 流程且无法验证 Access JWT 的第三方 MCP 服务器代码,请勿启用托管 OAuth。
- 在 Cloudflare 仪表板 ↗中,转到 Zero Trust > Access controls(访问控制)> Applications(应用程序)。
- 找到您要配置的 MCP 服务器应用程序,然后选择右侧的三个点 > Edit(编辑)。
- 转到 **Advanced settings(高级设置)**选项卡并开启 Managed OAuth(托管 OAuth)。
- (可选)配置托管 OAuth 设置。
- 选择 Save(保存)。
-
获取您现有的 Access 应用程序配置:
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: Apps and Policies Read
Get an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request GET \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -
发起一个
PUT请求,并将oauth_configuration.enabled设置为true。为了避免覆盖您现有的配置,请求体应包含上一个GET请求返回的所有字段。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies Write
Update an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request PUT \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "oauth_configuration": { "enabled": true } }'
若要进行测试,请打开一个 MCP 客户端并连接到受保护的 MCP 服务器。该客户端应打开一个浏览器窗口,提示您登录 Access。有关更多详细信息,请参阅授权流程部分。
托管 OAuth 可在 MCP 服务器门户上使用,是允许 MCP 客户端通过门户验证用户身份而无需浏览器 cookie 流程的机制。
- 在 Cloudflare 仪表板 ↗中,转到 Zero Trust > Access controls(访问控制)> AI controls(AI 控制)。
- 找到您要配置的门户,然后选择右侧的三个点 > Edit(编辑)。
- 转到 **Advanced settings(高级设置)**选项卡并开启 Managed OAuth(托管 OAuth)。
- (可选)配置托管 OAuth 设置。
- 选择 Save(保存)。
-
获取您门户底层 Access 应用程序的现有配置:
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: Apps and Policies Read
Get an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request GET \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -
发起一个
PUT请求,并将oauth_configuration.enabled设置为true。为了避免覆盖您现有的配置,请求体应包含上一个GET请求返回的所有字段。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies Write
Update an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request PUT \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "oauth_configuration": { "enabled": true } }'
若要进行测试,请打开一个 MCP 客户端并连接到 MCP 门户。该客户端应打开一个浏览器窗口,提示您登录 Access。有关更多详细信息,请参阅授权流程部分。
在您的自托管应用、MCP 服务器应用程序或MCP 服务器门户的 **Advanced settings(高级设置)**选项卡中配置这些设置。
- Allow localhost clients(允许 localhost 客户端):允许在
localhost上具有重定向 URI 的任何客户端。 - Allow loopback clients(允许环回客户端):允许在
127.0.0.1上具有重定向 URI 的任何客户端。 - Allowed redirect URIs(允许的重定向 URI):允许用于动态注册客户端的重定向 URI(例如,
https://playground.ai.cloudflare.com/*)。URL 必须使用https。路径可以以/*结尾以匹配所有子路径。 - Grant session duration(授权会话时长):OAuth 刷新令牌保持有效的时长。
- Access token lifetime(Access 令牌生命周期):OIDC Access 令牌可用于向您的应用程序进行身份验证的时长。Cloudflare 建议在配置较短的 **Access token lifetime(Access 令牌生命周期)(默认 15 分钟)**的同时,配置较长的 Grant session duration(授权会话时长)。当访问令牌过期时,Cloudflare 在根据您的 Access 策略重新评估用户后,使用刷新令牌签发一个新令牌。当刷新令牌过期时,用户必须向身份提供商重新进行身份验证。
通过 Access 应用程序端点上的 oauth_configuration 对象配置这些设置。
| 仪表板设置 | API 字段 |
|---|---|
| 允许 localhost 客户端 | dynamic_client_registration.allow_any_on_localhost |
| 允许环回客户端 | dynamic_client_registration.allow_any_on_loopback |
| 允许的重定向 URI | dynamic_client_registration.allowed_uris |
| 授权会话时长 | grant.session_duration |
| Access 令牌生命周期 | grant.access_token_lifetime |
-
获取您现有的 Access 应用程序配置:
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: Apps and Policies Read
Get an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request GET \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -
发送带有您的托管 OAuth 设置的
PUT请求。为了避免覆盖您现有的配置,PUT请求体应包含上一个GET请求返回的所有字段。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies Write
Update an Access applicationbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \ --request PUT \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "oauth_configuration": { "enabled": true, "dynamic_client_registration": { "enabled": true, "allow_any_on_localhost": true, "allow_any_on_loopback": true, "allowed_uris": [ "https://playground.ai.cloudflare.com/*" ] }, "grant": { "access_token_lifetime": "5m", "session_duration": "24h" } } }'
启用托管 OAuth 后,Access 将向非浏览器客户端返回 401 响应,而不是 302 重定向。该 401 响应包含一个 WWW-Authenticate 标头,该标头将客户端指向 Access 的 OAuth 发现元数据。
授权流程如下所示:
-
客户端从
/.well-known/端点获取 OAuth 授权服务器元数据:https://<your-app-domain>/.well-known/oauth-authorization-server此端点符合 RFC 8414 ↗ 和 RFC 9728 ↗ 标准,并返回应用程序的授权和令牌端点 URL。
-
客户端发起授权码流程。它将用户的浏览器打开到 Access 授权端点,用户照常登录其 IdP。
-
Access 向客户端签发一个 OAuth 访问令牌。客户端在向受保护应用程序发起的后续请求中使用此令牌。
托管 OAuth 签发**不透明(opaque)**的访问令牌(例如 oauth:CvNoo...),而不是 JSON Web Token (JWT)。这是有意设计的 —— OAuth 流程赋予客户端代表用户发起请求的能力,而不会向客户端泄露身份信息。
当客户端向您的应用程序出示不透明令牌时,Cloudflare 在后端将该令牌解析为用户的身份,并将已签名的断言转发给您的源站。从源站的角度来看,该请求与浏览器经过身份验证的请求看起来相同。
因为令牌是不透明的,所以客户端无法对其进行解码,也无法将其作为 JWT 直接转发到其他应用程序。若要向下游 Access 应用程序发起经过身份验证的请求,请使用关联应用令牌(Linked App Token)模式 —— 您的源站读取 Cf-Access-Jwt-Assertion 标头并将其作为 Cf-Access-Token 转发给下游应用程序。
如果您的 Access 应用程序配置了多个域,则通过任何一个域获取的 OAuth 令牌对于同一应用程序中的所有域均有效。用户只需进行一次身份验证,即可使用相同的令牌访问所有域,而无需其他提示。
当您有多个共享公共信任边界的内部服务时,这非常有用。您无需使用关联应用令牌策略配置独立的 Access 应用程序,而是可以将所有域添加到单个应用程序中,并通过托管 OAuth 进行一次身份验证。
托管 OAuth 和服务令牌都允许非浏览器客户端向受 Access 保护的应用程序进行身份验证,但它们适用于不同的用例:
| 托管 OAuth | 服务令牌 | |
|---|---|---|
| 身份验证模型 | 基于用户 —— 最终用户通过其身份提供商登录 | 基于机器 —— 共享密钥对服务本身进行身份验证 |
| 最适用于 | 交互式 CLI 工具、AI 代理、由人类发起请求的 SDK | 完全自动化的系统、计划任务 (cron jobs)、CI/CD 流水线、服务器对服务器的通信 |
| 用户身份 | Access 知道是哪个用户发起的请求 | 无用户身份 —— 请求归因于服务令牌 |
| 策略执行 | 可以使用基于身份的策略(例如,要求特定的组或电子邮件) | 需要 Service Auth 策略操作 |
| 凭证管理 | 无需分发共享密钥 —— 用户使用其自己的凭据进行身份验证 | 需要分发并轮换 Client ID 和 Client Secret |
当您希望非浏览器客户端以与浏览器相同的方式对用户进行身份验证时,请使用托管 OAuth —— 用户登录一次,客户端接收一个 OAuth 令牌代表其发起请求。
当没有人类参与且您需要机器身份以编程方式访问您的应用程序时,请使用服务令牌。