Skip to main content
  • 状态（Status）: Final
  • 类型（Type）: Standards Track
  • 创建（Created）: 2025-07-23
  • 作者（Author(s)）: Darin McAdams (@D-McAdams )
  • Issue: #1046

​
前言

标题（Title）: Support OAuth client credentials flow in authorization 作者（Author）: Darin McAdams (@D-McAdams ) 状态（Status）: Proposal 类型（Type）: Standards Track 创建（Created）: 2025-07-23

​
摘要

建议在授权规范中添加 OAuth 客户端凭据流，以支持机器对机器（machine-to-machine）场景。

​
动机

最初的授权规范提到过客户端凭据流，但在后续修订中被移除了。因此，规范目前对于如何解决没有终端用户进行交互式授权的机器对机器场景保持沉默。

​
规范

授权规范将被修订，把 OAuth 客户端凭据流列为允许的方式。遵循 OAuth 2.1 所确立的模式，本规范将**推荐（RECOMMEND）**使用 RFC 753 中定义的非对称方法（JWT 断言），但同时也允许客户端密钥。 作为对实现者的指导，规范概览也将被更新，以描述不同的流以及各自的适用场景。此外，为回应一个常见问题，规范将被更新，以表明实现者可以实现超出所定义范围的其他授权场景；强调本规范定义的是基线要求。

​
理由

为最大化互操作性（并最小化 SDK 复杂性），此变更将有意地将客户端凭据流约束为两个选项：
  1. 遵循 RFC 7523 的 JWT 断言（推荐（RECOMMENDED））
  2. 通过 HTTP Basic 认证的客户端密钥（为与既有系统最大化兼容而允许）
其他选项（如 mTLS）不包括在内。 虽然规范鼓励使用 RFC 7523（JWT 断言），但它尚未规定如何填充 JWT 内容，也未规定如何发现客户端的 JWKS URI 以验证 JWT。在规范的未来迭代中，这样做将是有益的。然而，目前这部分暂不规定，有待可以定义这些配置文件的其他 RFC 成熟。这些其他 RFC 包括 WIMSE Headless JWT Authentication（用于规定 JWT 内容）和 Client ID Metadata（用于规定 JWKS URI）。本次修订有意为这些未来的配置文件保留可扩展性。实际而言，这意味着需要尽快交付解决方案的实现者最有可能使用当今已被广泛支持的客户端密钥，而 JWT 断言模式则代表着更长期的方向。

​
向后兼容性

此变更完全向后兼容。它引入了一种新的授权流，但不改变既有的流。

​
安全影响

本规范引用既有的 OAuth 安全指南。