Claude for Office 自建 Entra 应用注册指南从graph_client_id到 GCC High 主权的完整配置路径【免费下载链接】financial-services可将 Claude 转变为金融服务专家适用于投资银行、股票研究等领域。提供核心及专项插件支持端到端工作流集成多数据源含技能、命令和连接器可定制适配企业需求。项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services本指南基于claude-for-msft-365-install插件用于配置 Claude Office 加载项直连你自己的云Vertex AI、Bedrock、Azure AI Foundry 或 LLM 网关的 entra-app.md 文档编写。当你的部署需要以自己的租户资源为令牌受众、或租户位于主权云时你必须注册属于自己的 EntraAzure AD应用而不是依赖 Anthropic 的默认多租户应用。读完本文你将掌握何时需要自建应用、完整的注册步骤重定向 URI、权限/API 配置、令牌版本、后端应校验的 JWT 声明以及 GCC High/DoD/21Vianet 主权云的差异与常见错误AADSTS50011、AADSTS65001等的排障方法。为什么需要注册自己的 Entra 应用Anthropic 的默认应用是一个多租户应用客户端 ID 为c2995f31-11e7-4882-b7a7-ef9def0a0266大多数配置下加载项直接使用它。但以下几种清单manifest配置要求令牌的aud受众必须指向你控制的资源或你的租户位于 Anthropic 应用不存在的主权云中此时就必须在你自己的租户中注册应用清单键为什么需要自己的应用graph_client_idOutlookGraph 权限是针对你的应用授予同意的而不是 Anthropic 的应用entra_scope访问令牌必须面向你的 API 资源gateway_auth_sourceentra你的网关——或 Foundry 资源——校验面向该资源的令牌graph_cloud≠globalAnthropic 的应用只存在于商业云从 manifest.md 可以确认默认情况下加载项会以 Anthropic 多租户应用的名义请求令牌其aud声明就是c2995f31-…这个 GUID只有当你的 bootstrap 端点或令牌交换服务要求aud与你租户中注册的应用匹配时才设置graph_client_idyour-app-guid。同理graph_cloud与graph_client_id是强绑定的——构建脚本会在任何非global的graph_cloud下强制要求graph_client_id否则登录会以不透明的AADSTS700016失败。注册应用入口与总体拓扑进入 Entra 管理中心 →应用注册App registrations→新注册New registration。选择单租户Single-tenant。最简单的拓扑是一个应用同时扮演两个角色客户端client——加载项以该应用的身份登录资源resource——你的后端校验面向该应用签发的令牌。如果你的安全策略不允许这种耦合也可以拆成两个应用一个客户端应用、一个资源应用例如网关场景下entra_scopeapi://resource-app-guid/access_as_user指向的是资源应用的 App ID URI。第 1 步配置重定向 URIRedirect URIs在身份验证Authentication→添加平台Add a platform→单页应用程序Single-page application中同时添加以下两个 URIURI用途brk-multihub://pivot.claude.aiNAA嵌套应用认证代理——桌面版 Office 和 Outlook 网页版。缺失会导致登录时报AADSTS50011https://pivot.claude.ai/msal-redirect.htmlSPA 回退——Office 网页版中的 Excel/Word/PowerPoint 不注入 NAA 桥需要此回退地址关键注意点两个 URI 都必须放在SPA 平台下而不是 Web 平台也不是移动/桌面平台。文档明确强调Both go under the SPA platform (not Web, not Mobile/desktop)——放错平台是AADSTS50011重定向 URI 不匹配的常见根源。第 2 步权限 / API 设置取决于令牌用途这里配置什么完全取决于令牌拿来干什么用例配置OutlookGraphAPI 权限→Microsoft Graph→ 委托权限Delegated→Mail.ReadWrite、Calendars.Read、People.Read、User.Read、offline_access网关 / bootstrap 认证entra_scope、gateway_auth_sourceentra公开 APIExpose an API→ 设置 Application ID URIapi://app-guid→添加作用域Add a scope例如access_as_user启用管理员同意。然后API 权限→我的 APIMy APIs→ 将该作用域添加为委托权限单应用拓扑中即应用授权给自己Foundry 直连、免密钥gateway_auth_sourceentraazure_resource_nameAPI 权限→Azure Cognitive Services→ 委托权限 →user_impersonation。不需要公开 API步骤——令牌面向 Azure 的https://cognitiveservices.azure.com而非你自己的应用因此设置entra_scopehttps://cognitiveservices.azure.com/.default。此外还需在 Foundry 资源上为每个用户授予Cognitive Services User角色Azure 门户 → 资源 →访问控制 (IAM)Bedrock WIFaws_role_arn不需要任何 API 权限——ID 令牌本身就是 web identity所有情况下最后都要在API 权限→为 tenant 授予管理员同意Grant admin consent for tenant。否则每个用户都会看到同意提示如果用户同意被禁用则直接被阻止。这同样也是 consent.md 中强调的前提entra_sso1生效前必须先完成管理员同意否则 NAA 登录对租户内每个用户都会失败。关于 Foundry 直连角色与作用域的重要澄清文档特别澄清了三个容易混淆的角色必须严格区分Cognitive Services User——数据平面角色用于直接模型推理。正确选择。Cognitive Services OpenAI User——仅限 OpenAI 模型不是本用例需要的。Foundry User / Azure AI User——旧称重命名后的角色用于 Foundry 的 agent 与项目平面另一个数据平面也不是本用例需要的。另外user_impersonation是委托权限服务于加载项的按用户交互式登录它不是服务端的 on-behalf-of 交换——Azure AI 资源不支持 OBO 流。为什么是cognitiveservices.azure.com而不是ai.azure.commanifest.md 中给出了底层原因加载项通过 NAA 让每个用户以自己的 Entra 应用登录这种按用户的委托流程与应用的 Azure Cognitive Servicesuser_impersonation权限配对其受众正是https://cognitiveservices.azure.com。这与 Claude Desktop 的 Foundry 登录使用的 scope 相同因此已为 Desktop 注册的 Entra 应用可以原样复用。而 Microsoft SDK 与托管身份文档使用的https://ai.azure.com/.default属于基于凭据的 SDK 流程DefaultAzureCredential、az login、服务主体并不使用应用注册的委托权限。Foundry 资源两种受众都接受但加载项的按用户登录必须用cognitiveservices.azure.com/.default。第 3 步令牌版本仅在你配置了Expose an API时在应用的清单Manifest中设置accessTokenAcceptedVersion: 2如果不设置Entra 会签发 v1.0 访问令牌——iss中没有/v2.0、没有preferred_username声明——大多数 JWT 中间件默认会拒绝。设置accessTokenAcceptedVersion: 2后签发的令牌使用 v2.0 声明集iss login.microsoftonline.com/tid/v2.0、azp、preferred_username。注意这一步只在你设置了Expose an API时才需要。对于Foundry 直连免密钥路径不要设置Expose an API或accessTokenAcceptedVersion——aud是https://cognitiveservices.azure.comscp是user_impersonationAzure 校验签名和受众后再根据用户在资源上的Cognitive Services User角色授权调用。你的后端校验什么对于entra_scope/gateway_auth_sourceentra加载项以Authorization: Bearer发送的访问令牌携带以下声明你的后端或网关必须校验声明期望值isshttps://login.microsoftonline.com/tenant-id/v2.0aud你的 Application ID URIapi://app-guidscp你公开的作用域空格分隔JWKShttps://login.microsoftonline.com/tenant-id/discovery/v2.0/keys对于Foundry 直连免密钥则没有你的后端——Azure 负责校验令牌aud为https://cognitiveservices.azure.comscp为user_impersonationAzure 校验签名与受众然后按用户在资源上的Cognitive Services User角色授权调用。同样地bootstrap.md 给出了 bootstrap 端点的完整校验清单aud应为c2995f31-…默认应用 ID或你自己的应用 GUID设置了graph_client_id时iss必须精确匹配你的租户exp不能过期oid才是用户查找键——邮箱upn/preferred_username可能变化oid不会。如果你设置了entra_scopeBearer 是访问令牌而非 ID 令牌此时校验aud 你的 API 的 Application ID URIapi://guid不是客户端 GUID并检查scp是否包含你定义的作用域。签名校验必须使用 Microsoft 的 JWKS并使用成熟的库Node 用josePython 用PyJWTcryptography.NET 用Microsoft.IdentityModel.Tokens——手工实现 JWT 校验正是安全漏洞的温床。仓库中的参考实现 examples/python-bootstrap/app.py 完整演示了这一校验逻辑validate()从Authorization: Bearer头提取令牌通过PyJWKClient拉取 JWKS 或使用本地开发用DEV_JWKS_PATH密钥然后调用jwt.decode(token, key, algorithms[RS256], audienceAUDIENCE, issuerISSUER)精确校验受众与签发者config.py 中AUDIENCE默认为c2995f31-11e7-4882-b7a7-ef9def0a0266ISSUER由TENANT_ID环境变量拼出https://login.microsoftonline.com/tenant/v2.0。GCC High / DoD / 21Vianet 主权云同一套步骤但门户与端点不同——应用不会跨 Microsoft 国家云复制。清单键graph_cloud是单一枚举值从不为 URL每个值映射到 Microsoft 国家云部署文档中固定的 Graph Entra 端点对租户graph_cloud备注商业云或 GCCglobal默认值可省略GCC Highus-gov-high自动检测在评审过的清单中显式设置以固定US Gov DoDus-gov-dod始终必须显式设置——DoD 与 GCC High 共享权威主机自动检测会选到 GCC High中国21Vianetchina自动检测显式设置以固定主权云部署的差异要点在何处注册在portal.azure.us美国政务或portal.azure.cn21Vianet注册而不是商业门户。重定向 URI 不变——brk-multihub://pivot.claude.ai与https://pivot.claude.ai/msal-redirect.html在任何云中加载项都从同一域提供。清单——按 manifest.md 中的主权云表格添加graph_cloudus-gov-high或us-gov-dod、china。构建脚本强制与加载项加载时相同的规则无法识别的值是硬错误任何非global的graph_cloud都要求graph_client_id。graph_cloud同样管辖 Word/Excel/PowerPoint 的 Entra SSO 权威——它们共享认证路径——所以设置它时office清单也要带上。管理员同意 URL使用主权权威https://login.microsoftonline.us/tenant-id/adminconsent?client_idapp-id后端校验——令牌的iss与 JWKS 使用.us主机https://login.microsoftonline.us/tenant-id/v2.0与https://login.microsoftonline.us/tenant-id/discovery/v2.0/keys。钉在.com上的校验器会拒绝所有请求。这条同样适用于认证链中的任何 AWS OIDC 身份提供方.us签发的 idToken 的 issuer 是https://login.microsoftonline.us/{tenant}/v2.0你的 AWS OIDC identity provider 必须配置为该 issuer而不是.com的那个。排障指南AADSTS50011重定向 URI 不匹配两个 URI 之一缺失或者被添加到了错误的平台下必须是 SPA 平台。回到第 1 步检查。Outlook for Mac 上的Tag: 9n156主机的认证代理无法完成登录。几乎总是主权云账户在访问注册于商业云的应用修复方法在portal.azure.us注册并设置graph_cloud。如果应用已经在正确的云中检查条件访问Conditional Access——已弃用的要求已批准的客户端应用Require approved client app授权会阻止 NAA。对话框中的 Correlation Id 可以在你的 Entra 登录日志中解析而不是 Anthropic 的日志。AADSTS65001需要同意授予管理员同意没有被点击或者同意之后又添加了权限需要重新授予。相关排障补充debug.md 补充了与 Entra 应用配置直接相关的两个症状AADSTS50194: …not configured as a multi-tenant application / Use a tenant-specific endpoint——你的graph_client_id或entra_scope资源应用是单租户应用而加载项构建版本较旧仍以/common权威请求令牌较新构建在设置graph_client_id时自动解析租户特定权威修复方式是更新加载项版本旧版本没有清单级变通方案entra_scope requires graph_client_id——设置了entra_scope却没有graph_client_id自定义作用域的访问令牌必须由你自己的 Entra 应用签发不能使用默认应用构建脚本也会拒绝这种配对。与其它命令文档的衔接本页是唯一的注册步骤集合各功能文档都链接到这里并指明权限表的哪一行适用manifest.md 中的Entra SSO一节说明了graph_client_id、entra_scope、gateway_auth_sourceentra在清单构建脚本中的配对约束entra_scope要求graph_client_idgateway_auth_sourceentra要求entra_scope并隐含gateway_auth_headerauthorization两者都是仅限清单的键加载项需要在读取扩展属性或调用 bootstrap 端点之前初始化 NAAsetup.md 的Azure AI Foundry一节给出了免密钥keyless路径的完整捕获清单azure_resource_name、entra_sso1、graph_client_id、entra_scopehttps://cognitiveservices.azure.com/.default、gateway_auth_sourceentraconsent.md 覆盖的是 Anthropic 默认应用的管理员同意 URL——设置了自己的graph_client_id后同意管理转移到你自己的应用上本页不再适用。一句话总结当你需要令牌的aud指向自己控制的资源或租户位于主权云时注册一个单租户 Entra 应用——SPA 平台下配好两个重定向 URI按令牌用途配置权限Graph 委托权限 / 自公开作用域 / Azure Cognitive Servicesuser_impersonation设置accessTokenAcceptedVersion: 2为租户授予管理员同意然后让后端按iss/aud/scp/JWKS 四项精确校验。【免费下载链接】financial-services可将 Claude 转变为金融服务专家适用于投资银行、股票研究等领域。提供核心及专项插件支持端到端工作流集成多数据源含技能、命令和连接器可定制适配企业需求。项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude for Office 自建 Entra 应用注册指南：从 `graph_client_id` 到 GCC High 主权的完整配置路径
Claude for Office 自建 Entra 应用注册指南从graph_client_id到 GCC High 主权的完整配置路径【免费下载链接】financial-services可将 Claude 转变为金融服务专家适用于投资银行、股票研究等领域。提供核心及专项插件支持端到端工作流集成多数据源含技能、命令和连接器可定制适配企业需求。项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services本指南基于claude-for-msft-365-install插件用于配置 Claude Office 加载项直连你自己的云Vertex AI、Bedrock、Azure AI Foundry 或 LLM 网关的 entra-app.md 文档编写。当你的部署需要以自己的租户资源为令牌受众、或租户位于主权云时你必须注册属于自己的 EntraAzure AD应用而不是依赖 Anthropic 的默认多租户应用。读完本文你将掌握何时需要自建应用、完整的注册步骤重定向 URI、权限/API 配置、令牌版本、后端应校验的 JWT 声明以及 GCC High/DoD/21Vianet 主权云的差异与常见错误AADSTS50011、AADSTS65001等的排障方法。为什么需要注册自己的 Entra 应用Anthropic 的默认应用是一个多租户应用客户端 ID 为c2995f31-11e7-4882-b7a7-ef9def0a0266大多数配置下加载项直接使用它。但以下几种清单manifest配置要求令牌的aud受众必须指向你控制的资源或你的租户位于 Anthropic 应用不存在的主权云中此时就必须在你自己的租户中注册应用清单键为什么需要自己的应用graph_client_idOutlookGraph 权限是针对你的应用授予同意的而不是 Anthropic 的应用entra_scope访问令牌必须面向你的 API 资源gateway_auth_sourceentra你的网关——或 Foundry 资源——校验面向该资源的令牌graph_cloud≠globalAnthropic 的应用只存在于商业云从 manifest.md 可以确认默认情况下加载项会以 Anthropic 多租户应用的名义请求令牌其aud声明就是c2995f31-…这个 GUID只有当你的 bootstrap 端点或令牌交换服务要求aud与你租户中注册的应用匹配时才设置graph_client_idyour-app-guid。同理graph_cloud与graph_client_id是强绑定的——构建脚本会在任何非global的graph_cloud下强制要求graph_client_id否则登录会以不透明的AADSTS700016失败。注册应用入口与总体拓扑进入 Entra 管理中心 →应用注册App registrations→新注册New registration。选择单租户Single-tenant。最简单的拓扑是一个应用同时扮演两个角色客户端client——加载项以该应用的身份登录资源resource——你的后端校验面向该应用签发的令牌。如果你的安全策略不允许这种耦合也可以拆成两个应用一个客户端应用、一个资源应用例如网关场景下entra_scopeapi://resource-app-guid/access_as_user指向的是资源应用的 App ID URI。第 1 步配置重定向 URIRedirect URIs在身份验证Authentication→添加平台Add a platform→单页应用程序Single-page application中同时添加以下两个 URIURI用途brk-multihub://pivot.claude.aiNAA嵌套应用认证代理——桌面版 Office 和 Outlook 网页版。缺失会导致登录时报AADSTS50011https://pivot.claude.ai/msal-redirect.htmlSPA 回退——Office 网页版中的 Excel/Word/PowerPoint 不注入 NAA 桥需要此回退地址关键注意点两个 URI 都必须放在SPA 平台下而不是 Web 平台也不是移动/桌面平台。文档明确强调Both go under the SPA platform (not Web, not Mobile/desktop)——放错平台是AADSTS50011重定向 URI 不匹配的常见根源。第 2 步权限 / API 设置取决于令牌用途这里配置什么完全取决于令牌拿来干什么用例配置OutlookGraphAPI 权限→Microsoft Graph→ 委托权限Delegated→Mail.ReadWrite、Calendars.Read、People.Read、User.Read、offline_access网关 / bootstrap 认证entra_scope、gateway_auth_sourceentra公开 APIExpose an API→ 设置 Application ID URIapi://app-guid→添加作用域Add a scope例如access_as_user启用管理员同意。然后API 权限→我的 APIMy APIs→ 将该作用域添加为委托权限单应用拓扑中即应用授权给自己Foundry 直连、免密钥gateway_auth_sourceentraazure_resource_nameAPI 权限→Azure Cognitive Services→ 委托权限 →user_impersonation。不需要公开 API步骤——令牌面向 Azure 的https://cognitiveservices.azure.com而非你自己的应用因此设置entra_scopehttps://cognitiveservices.azure.com/.default。此外还需在 Foundry 资源上为每个用户授予Cognitive Services User角色Azure 门户 → 资源 →访问控制 (IAM)Bedrock WIFaws_role_arn不需要任何 API 权限——ID 令牌本身就是 web identity所有情况下最后都要在API 权限→为 tenant 授予管理员同意Grant admin consent for tenant。否则每个用户都会看到同意提示如果用户同意被禁用则直接被阻止。这同样也是 consent.md 中强调的前提entra_sso1生效前必须先完成管理员同意否则 NAA 登录对租户内每个用户都会失败。关于 Foundry 直连角色与作用域的重要澄清文档特别澄清了三个容易混淆的角色必须严格区分Cognitive Services User——数据平面角色用于直接模型推理。正确选择。Cognitive Services OpenAI User——仅限 OpenAI 模型不是本用例需要的。Foundry User / Azure AI User——旧称重命名后的角色用于 Foundry 的 agent 与项目平面另一个数据平面也不是本用例需要的。另外user_impersonation是委托权限服务于加载项的按用户交互式登录它不是服务端的 on-behalf-of 交换——Azure AI 资源不支持 OBO 流。为什么是cognitiveservices.azure.com而不是ai.azure.commanifest.md 中给出了底层原因加载项通过 NAA 让每个用户以自己的 Entra 应用登录这种按用户的委托流程与应用的 Azure Cognitive Servicesuser_impersonation权限配对其受众正是https://cognitiveservices.azure.com。这与 Claude Desktop 的 Foundry 登录使用的 scope 相同因此已为 Desktop 注册的 Entra 应用可以原样复用。而 Microsoft SDK 与托管身份文档使用的https://ai.azure.com/.default属于基于凭据的 SDK 流程DefaultAzureCredential、az login、服务主体并不使用应用注册的委托权限。Foundry 资源两种受众都接受但加载项的按用户登录必须用cognitiveservices.azure.com/.default。第 3 步令牌版本仅在你配置了Expose an API时在应用的清单Manifest中设置accessTokenAcceptedVersion: 2如果不设置Entra 会签发 v1.0 访问令牌——iss中没有/v2.0、没有preferred_username声明——大多数 JWT 中间件默认会拒绝。设置accessTokenAcceptedVersion: 2后签发的令牌使用 v2.0 声明集iss login.microsoftonline.com/tid/v2.0、azp、preferred_username。注意这一步只在你设置了Expose an API时才需要。对于Foundry 直连免密钥路径不要设置Expose an API或accessTokenAcceptedVersion——aud是https://cognitiveservices.azure.comscp是user_impersonationAzure 校验签名和受众后再根据用户在资源上的Cognitive Services User角色授权调用。你的后端校验什么对于entra_scope/gateway_auth_sourceentra加载项以Authorization: Bearer发送的访问令牌携带以下声明你的后端或网关必须校验声明期望值isshttps://login.microsoftonline.com/tenant-id/v2.0aud你的 Application ID URIapi://app-guidscp你公开的作用域空格分隔JWKShttps://login.microsoftonline.com/tenant-id/discovery/v2.0/keys对于Foundry 直连免密钥则没有你的后端——Azure 负责校验令牌aud为https://cognitiveservices.azure.comscp为user_impersonationAzure 校验签名与受众然后按用户在资源上的Cognitive Services User角色授权调用。同样地bootstrap.md 给出了 bootstrap 端点的完整校验清单aud应为c2995f31-…默认应用 ID或你自己的应用 GUID设置了graph_client_id时iss必须精确匹配你的租户exp不能过期oid才是用户查找键——邮箱upn/preferred_username可能变化oid不会。如果你设置了entra_scopeBearer 是访问令牌而非 ID 令牌此时校验aud 你的 API 的 Application ID URIapi://guid不是客户端 GUID并检查scp是否包含你定义的作用域。签名校验必须使用 Microsoft 的 JWKS并使用成熟的库Node 用josePython 用PyJWTcryptography.NET 用Microsoft.IdentityModel.Tokens——手工实现 JWT 校验正是安全漏洞的温床。仓库中的参考实现 examples/python-bootstrap/app.py 完整演示了这一校验逻辑validate()从Authorization: Bearer头提取令牌通过PyJWKClient拉取 JWKS 或使用本地开发用DEV_JWKS_PATH密钥然后调用jwt.decode(token, key, algorithms[RS256], audienceAUDIENCE, issuerISSUER)精确校验受众与签发者config.py 中AUDIENCE默认为c2995f31-11e7-4882-b7a7-ef9def0a0266ISSUER由TENANT_ID环境变量拼出https://login.microsoftonline.com/tenant/v2.0。GCC High / DoD / 21Vianet 主权云同一套步骤但门户与端点不同——应用不会跨 Microsoft 国家云复制。清单键graph_cloud是单一枚举值从不为 URL每个值映射到 Microsoft 国家云部署文档中固定的 Graph Entra 端点对租户graph_cloud备注商业云或 GCCglobal默认值可省略GCC Highus-gov-high自动检测在评审过的清单中显式设置以固定US Gov DoDus-gov-dod始终必须显式设置——DoD 与 GCC High 共享权威主机自动检测会选到 GCC High中国21Vianetchina自动检测显式设置以固定主权云部署的差异要点在何处注册在portal.azure.us美国政务或portal.azure.cn21Vianet注册而不是商业门户。重定向 URI 不变——brk-multihub://pivot.claude.ai与https://pivot.claude.ai/msal-redirect.html在任何云中加载项都从同一域提供。清单——按 manifest.md 中的主权云表格添加graph_cloudus-gov-high或us-gov-dod、china。构建脚本强制与加载项加载时相同的规则无法识别的值是硬错误任何非global的graph_cloud都要求graph_client_id。graph_cloud同样管辖 Word/Excel/PowerPoint 的 Entra SSO 权威——它们共享认证路径——所以设置它时office清单也要带上。管理员同意 URL使用主权权威https://login.microsoftonline.us/tenant-id/adminconsent?client_idapp-id后端校验——令牌的iss与 JWKS 使用.us主机https://login.microsoftonline.us/tenant-id/v2.0与https://login.microsoftonline.us/tenant-id/discovery/v2.0/keys。钉在.com上的校验器会拒绝所有请求。这条同样适用于认证链中的任何 AWS OIDC 身份提供方.us签发的 idToken 的 issuer 是https://login.microsoftonline.us/{tenant}/v2.0你的 AWS OIDC identity provider 必须配置为该 issuer而不是.com的那个。排障指南AADSTS50011重定向 URI 不匹配两个 URI 之一缺失或者被添加到了错误的平台下必须是 SPA 平台。回到第 1 步检查。Outlook for Mac 上的Tag: 9n156主机的认证代理无法完成登录。几乎总是主权云账户在访问注册于商业云的应用修复方法在portal.azure.us注册并设置graph_cloud。如果应用已经在正确的云中检查条件访问Conditional Access——已弃用的要求已批准的客户端应用Require approved client app授权会阻止 NAA。对话框中的 Correlation Id 可以在你的 Entra 登录日志中解析而不是 Anthropic 的日志。AADSTS65001需要同意授予管理员同意没有被点击或者同意之后又添加了权限需要重新授予。相关排障补充debug.md 补充了与 Entra 应用配置直接相关的两个症状AADSTS50194: …not configured as a multi-tenant application / Use a tenant-specific endpoint——你的graph_client_id或entra_scope资源应用是单租户应用而加载项构建版本较旧仍以/common权威请求令牌较新构建在设置graph_client_id时自动解析租户特定权威修复方式是更新加载项版本旧版本没有清单级变通方案entra_scope requires graph_client_id——设置了entra_scope却没有graph_client_id自定义作用域的访问令牌必须由你自己的 Entra 应用签发不能使用默认应用构建脚本也会拒绝这种配对。与其它命令文档的衔接本页是唯一的注册步骤集合各功能文档都链接到这里并指明权限表的哪一行适用manifest.md 中的Entra SSO一节说明了graph_client_id、entra_scope、gateway_auth_sourceentra在清单构建脚本中的配对约束entra_scope要求graph_client_idgateway_auth_sourceentra要求entra_scope并隐含gateway_auth_headerauthorization两者都是仅限清单的键加载项需要在读取扩展属性或调用 bootstrap 端点之前初始化 NAAsetup.md 的Azure AI Foundry一节给出了免密钥keyless路径的完整捕获清单azure_resource_name、entra_sso1、graph_client_id、entra_scopehttps://cognitiveservices.azure.com/.default、gateway_auth_sourceentraconsent.md 覆盖的是 Anthropic 默认应用的管理员同意 URL——设置了自己的graph_client_id后同意管理转移到你自己的应用上本页不再适用。一句话总结当你需要令牌的aud指向自己控制的资源或租户位于主权云时注册一个单租户 Entra 应用——SPA 平台下配好两个重定向 URI按令牌用途配置权限Graph 委托权限 / 自公开作用域 / Azure Cognitive Servicesuser_impersonation设置accessTokenAcceptedVersion: 2为租户授予管理员同意然后让后端按iss/aud/scp/JWKS 四项精确校验。【免费下载链接】financial-services可将 Claude 转变为金融服务专家适用于投资银行、股票研究等领域。提供核心及专项插件支持端到端工作流集成多数据源含技能、命令和连接器可定制适配企业需求。项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考