> ## Documentation Index > Fetch the complete documentation index at: https://mcp-zh.com/llms.txt > Use this file to discover all available pages before exploring further. # 授权章程 > MCP 授权兴趣组的章程。 ## 群组类型 **兴趣组** ## 使命陈述 授权兴趣组是 MCP 授权工作唯一获章程认可的场所。它汇聚 MCP 实现者、身份提供方厂商和安全从业者，共同揭示现实世界的授权问题、判定它们是否值得解决以及是否应归入 MCP，并为作者提供一个可靠的场所，以呈现 [SEP](/community/sep-guidelines)、[ext-auth](https://github.com/modelcontextprotocol/ext-auth) 草案、原型和部署结果，获取跨主题反馈。章程界定范围；讨论和粗略共识在一个频道和一场定期电话会议中发生，而工作产物是草案和演示，而非新的常设群组。 ## 范围 ### 范围内 * **部署经验报告**：实现者如何将当前的授权规范（OAuth 2.1、[RFC 9728](https://www.rfc-editor.org/rfc/rfc9728) 受保护资源元数据、[RFC 7591](https://www.rfc-editor.org/rfc/rfc7591) 动态客户端注册、客户端 ID 元数据文档）与真实的授权服务器集成，以及其不足之处 * **扩展互操作性报告**：将 [ext-auth](https://github.com/modelcontextprotocol/ext-auth) 扩展的独立实现端到端配对的结果（例如通过[企业托管授权](/extensions/auth/enterprise-managed-authorization) ID-JAG 交换将 IdP、客户端和授权服务器配对），包括 IdP 能力缺口、变通办法和合规场景输入 * **企业身份集成**：将 MCP 服务器连接到企业 IdP（Okta、Entra ID、Ping、Keycloak 等）时的需求和摩擦点，包括 SSO、租户隔离和管理员同意流程 * **委托与代理式访问**：当 MCP 客户端通过代理或工具链行事时，代表（on-behalf-of）令牌交换、下游资源访问、受众限制和同意的用例 * **作用域和权限粒度**：MCP 服务器是否以及如何公告细粒度作用域（逐工具、逐资源），客户端应如何请求和呈现它们，以及超出作用域字符串的授权粒度（丰富授权请求、结构化拒绝、补救提示） * **非 HTTP 传输的凭据**：针对 stdio、WebSocket 及未来传输的模式，这些传输不直接适用 HTTP 授权规范 * **客户端身份与注册**：运营者对动态客户端注册、客户端 ID 元数据文档、软件声明和预注册客户端的经验 * **威胁建模输入**：编目与授权相关的攻击面（令牌混淆、混淆代理、受众不匹配、重定向处理），为《安全最佳实践》文档提供依据 * **SEP 和草案反馈**：与授权相关的 SEP、ext-auth 草案、参考实现和演示，在 [SEP 流程](/community/sep-guidelines)之前和期间于电话会议上及 `#auth-ig` 话题中呈现以获取反馈；本 IG 的粗略共识记录在会议纪要中，供担保人和核心维护者参考 * **问题陈述与需求**：在 `#auth-ig` 话题和 SEP pull request 上分享的用例目录和建议，供 SEP 作者使用 ### 范围外 * **接受 SEP 或扩展**：本 IG 提供反馈并表达支持；担保和接受遵循 [SEP 指南](/community/sep-guidelines)，仍归维护者和核心维护者 * **终端用户对 MCP 客户端的认证**：宿主应用如何认证自己的用户是宿主的关注点，而非协议的关注点 * **传输安全（TLS、mTLS、证书处理）**：属于 Transports 工作组 * **服务器身份、来源和信任信号**：属于 Server Card / Registry 相关工作 * **终端用户产品配置演练**：本 IG 讨论模式，而非针对个别 IdP 产品的分步设置。厂商报告的关于某个授权服务器或 IdP 能否实现某功能的约束，作为部署经验**属于**范围内 * **具有竞争敏感性或非公开的商业信息**，依据 [MCP 反垄断政策](/community/antitrust) ### 相关群组 * **[安全 IG](/community/interest-groups/security)**：令牌受众混淆、签发者验证和账户关联风险，处于两个群组之间的边界 * **[Transports 工作组](/community/working-groups/transports)**：授权目前在 HTTP 传输层规定；对传输的变更会影响凭据在何处承载 * **Agents 工作组**：多代理链的委托/代表访问和同意，与代理式用例大量重叠 * **[Server Card 工作组](/community/working-groups/server-card) / [Registry](/community/working-groups/registry)**：客户端和服务器身份、发现元数据和信任建立，与如何定位和验证授权服务器及资源服务器相交叉 * **SDK 维护者**：SDK 交付授权客户端实现；IG 的发现应为跨 SDK 的授权工效学和默认值提供依据 ## 领导层 | 角色 | 姓名 | 组织 | GitHub | 任期 | | --- | ------------- | --------- | ------------------------------------------ | -- | | 主持人 | Aaron Parecki | Okta | [@aaronpk](https://github.com/aaronpk) | 首任 | | 主持人 | Darin McAdams | Amazon | [@D-McAdams](https://github.com/D-McAdams) | 首任 | | 主持人 | Paul Carleton | Anthropic | [@pcarleton](https://github.com/pcarleton) | 首任 | ## 成员 向任何人开放；加入频道、参加电话会议或做贡献都无需正式的成员资格或批准步骤。本群组尤其欢迎身份提供方厂商、正在交付授权支持的 MCP 客户端和服务器实现者，以及将 MCP 与企业 IdP 集成的运营者。 加入 [MCP 贡献者 Discord](/community/communication#discord) 上的 `#auth-ig` 频道，并为你的主题发起或加入一个话题。电话会议是开放的，出席是可选的——在 Discord 话题中的异步参与同样受到重视。 ## 运作 | 会议 | 频率 | 时长 | 目的 | | ---------- | ----- | ----- | --------------------------- | | 授权 IG 电话会议 | 每 2 周 | 45 分钟 | 议程驱动：问题提案、SEP 和草案进展、演示、部署报告 | Discord：[#auth-ig](https://discord.com/channels/1358869848138059966/1360835991749001368) ### 一个频道，每主题一个话题 所有授权讨论都在 `#auth-ig` 中进行，每个主题一个 Discord 话题（例如一个 SEP 编号、一个草案名称或一次部署配对）。不设逐主题的频道。会议议程和纪要位于该频道的每次会议议程话题中，并按[群组治理规则](/community/working-interest-groups)的要求，将链接交叉发布到 [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions)。 ### 议程驱动的电话会议 电话会议保持固定的双周时段，但每次会议都根据其议程构建： 1. 一位主持人在每次会议前于 `#auth-ig` 中开一个议程话题。任何人都可以通过回复主题、诉求（反馈、决策、知会）和所需时间来申请一个时段。 2. 主持人在会议前商定议程并分配时段。 3. 如果议程内容单薄，则在话题中取消该次会议，时段留作下次使用。 典型的时段是一个问题提案、一个 SEP 或 ext-auth 草案的进度更新、一个原型或参考实现的演示，或来自已交付扩展的实现者的部署或互操作性报告。 ### 从问题到 SEP 在任何人投入撰写 SEP 之前，对每个问题提案都会提出两个常设问题： * **这是一个值得解决的问题吗？** 是否存在真实的部署需求，且缺口在于协议本身而非某个产品？ * **它应归于此处吗？** 合适的归处是核心规范、ext-auth 中的官方扩展、非官方扩展，还是上游标准机构？ 当两者的答案都是"是"时，提议者通过正常的 [SEP 流程](/community/sep-guidelines)起草一个 SEP 或 ext-auth pull request，找到一位担保人，并随着草案成熟回到电话会议呈现进展和演示。本 IG 不为每个主题设立子群组、频道或系列会议。已经就某主题单独会晤的贡献者欢迎继续这样做，并将成果作为议程时段带回电话会议。当某个交付物确实需要其自身的决策权时，仍可通过标准流程提议一个单独的[工作组](/community/working-interest-groups)，但这是例外而非默认路径。 ## 交付物与成功指标 本 IG 的产出是经其流转的草案和演示：带有记录在案的 IG 反馈的授权 SEP 和 ext-auth 规范、参考实现和合规场景、互操作性和部署报告，以及已发布的会议纪要。本 IG 管理 [modelcontextprotocol/ext-auth](https://github.com/modelcontextprotocol/ext-auth)，授权扩展规范经由 PR 在此落地。成功的样子是：授权提案在已纳入跨主题反馈的情况下进入核心维护者评审，以及已交付的扩展积累起独立的、可互操作的实现。 ### 已合并的频道 以下 Discord 频道此前承载授权子群组。自本次重订章程起，它们已归档（只读），其主题作为 `#auth-ig` 话题和议程时段延续。[企业托管授权 IG](/community/interest-groups/enterprise-managed-authorization) 在相同基础上并入本群组：EMA 实现者将互操作性和部署进展作为演示时段带到电话会议，而非带到一个常设的单独群组。 | 原频道 | 主题 | 合并时状态 | 延续为 | | ------------------------------ | --------------------------------------------------------------------- | ----- | ------------------------------- | | `#auth-wg-client-registration` | 动态客户端注册、客户端 ID 元数据文档、软件声明、预注册 | 已完成 | 按需的 `#auth-ig` 话题 | | `#auth-wg-mixup-protection` | 授权服务器混淆和令牌受众混淆的缓解措施 | 已完成 | 按需的 `#auth-ig` 话题 | | `#auth-wg-profiles` | 客户端凭据、企业托管授权、DPoP、工作负载身份联合扩展 | 已完成 | `#auth-ig` 的 DPoP 和工作负载身份联合话题 | | `#auth-wg-tool-scopes` | 逐工具作用域公告、升级授权、客户端侧作用域累积 | 活跃 | `#auth-ig` 话题 | | `#auth-wg-fine-grained-authz` | 丰富授权请求（[RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)）、结构化拒绝、补救提示 | 活跃 | `#auth-ig` 的 SEP-2643 / 细粒度授权话题 | | `#auth-wg-improve-devx` | 超出规范性规范的最佳实践指导和教程 | 休眠 | 按需的 `#auth-ig` 话题 | | `#enterprise-managed-auth-ig` | EMA 扩展互操作性（IdP、客户端、授权服务器） | 活跃 | `#auth-ig` 的 EMA 互操作话题和部署报告时段 | ## 变更日志 | 日期 | 变更 | | ---------- | ------------------------------------------------------------------- | | 2026-08-17 | 重订章程：授权工作的单一场所和频道；议程驱动的电话会议；SEP 反馈纳入范围；`#auth-wg-*` 频道和企业托管授权 IG 并入 | | 2026-06-02 | 首版章程 |