OAuth 2.1 授权框架

1.3.1. 授权码

授权码是一种用于获取 访问令牌的临时凭据。 客户端不会 直接向资源所有者请求授权，而是将 资源所有者引导至授权服务器（通过其 用户代理），授权服务器随后携带授权码将 资源所有者引导回客户端。 客户端随后可以用授权码交换访问令牌。¶

在携带授权码将资源所有者引导回客户端之前， 授权服务器会认证 资源所有者，并且可以请求资源所有者同意，或者以其他方式 告知其客户端的请求。由于资源所有者 只与授权服务器进行认证，因此资源 所有者的凭据永远不会与客户端共享，并且客户端 无需了解任何额外的认证步骤， 例如多因素认证或委托账户。¶

授权码提供了若干重要的安全优势， 例如能够认证客户端，以及 将访问令牌直接传输给客户端，而无需 通过资源所有者的用户代理传递，从而避免可能 将其暴露给其他方，包括资源所有者。¶

1.3.2. 刷新令牌

刷新令牌是用于获取访问令牌的凭据。刷新 令牌可以由授权服务器颁发给客户端，并 用于在当前访问令牌 失效或过期时获取新的访问令牌，或者获取 作用域相同或更窄的其他访问令牌（访问令牌可以具有比资源 所有者所授权的更短生命周期和更少 权限）。是否颁发刷新令牌由 授权服务器自行决定，是可选的，并且可以基于客户端的属性、 请求的属性、授权服务器内部的策略或 任何其他标准。如果授权服务器颁发刷新 令牌，则会在颁发访问令牌时将其一并包含（即 图 2中的步骤 (2)）。刷新令牌的生命周期同样 由授权服务器自行决定。¶

刷新令牌是表示资源所有者授予 客户端的授权的字符串。对于 客户端而言，该字符串被视为不透明值。刷新令牌可以是用于检索 授权信息的标识符，也可以将这些信息编码到 字符串本身中。与访问令牌不同，刷新令牌 仅供授权服务器使用，绝不会发送 给资源服务器。¶

+--------+                                           +---------------+
|        |--(1)---------- 授权许可 ----------------->|               |
|        |                                           |               |
|        |<-(2)---------- 访问令牌 -----------------|               |
|        |               & 刷新令牌                 |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(3)---- 访问令牌 -------->|          |   |               |
|        |                            |          |   |               |
|        |<-(4)--- 受保护资源 --------|   资源   |   |     授权      |
| 客户端 |                            |   服务器  |   |     服务器     |
|        |--(5)---- 访问令牌 -------->|          |   |               |
|        |                            |          |   |               |
|        |<-(6)--- 无效令牌错误 ------|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(7)---------- 刷新令牌 ----------------->|               |
|        |                                           |               |
|        |<-(8)---------- 访问令牌 -----------------|               |
+--------+           & 可选刷新令牌                  +---------------+

图 2中所示的流程包括以下步骤：¶

1. 客户端通过向 授权服务器进行认证并提交授权许可来请求访问令牌。¶

2. 授权服务器认证客户端并 验证授权许可，如果有效，则颁发访问令牌 以及可选的刷新令牌。¶

3. 客户端通过向资源 服务器提交访问令牌来发出受保护资源请求。¶

4. 资源服务器验证访问令牌，如果 有效，则处理请求。¶

5. 重复步骤 (3) 和 (4)，直到访问令牌过期。 如果 客户端知道访问令牌已过期，则跳到步骤 (7)； 否则，它会再次发出受保护资源请求。¶

6. 由于访问令牌无效，资源服务器 返回无效令牌错误。¶

7. 客户端通过提交刷新令牌 请求新的访问令牌，并且如果已向其颁发凭据，则提供客户端认证。 客户端认证要求基于客户端类型 以及授权服务器策略。¶

8. 授权服务器认证客户端并 验证刷新令牌，如果有效，则颁发新的访问令牌（以及 可选的新刷新令牌）。¶

请注意，无需将刷新 令牌的生命周期告知客户端，因为即使客户端知道 该生命周期，也无法采取不同的操作。此外，授权服务器 可能选择使用动态生命周期（例如，只要刷新令牌至少每 7 天使用一次， 就延长刷新令牌的到期时间）， 或者授权服务器可能出于任何原因在 计划到期日期之前撤销刷新令牌，例如用户 撤销应用程序的访问权限。这意味着客户端本来就必须 处理刷新令牌在任意时间到期的情况。¶

无论刷新令牌为何或何时过期，客户端 都只有一种获取新令牌的途径，即从头开始新的 OAuth 流程。因此，没有定义任何 用于向客户端传达刷新令牌过期时间的属性。¶

1.3.3. 客户端凭据

当授权作用域仅限于 客户端控制的受保护资源， 或仅限于此前已与授权服务器安排好的受保护资源时， 客户端凭据或其他形式的客户端认证 （例如用于签署 JWT 的私钥，如 [RFC7523] 及其更新 [I-D.ietf-oauth-rfc7523bis] 中所述） 可以用作授权许可。客户端凭据用于客户端根据 先前与授权服务器安排好的授权请求 访问受保护资源的情况。¶

1.4.1. 访问令牌作用域

访问令牌旨在向客户端颁发比 授予访问权限的用户所拥有权限更少的 权限。这称为具有有限“作用域”的 访问令牌。授权服务器和资源服务器可以使用这种 作用域机制来限制特定客户端可以访问哪些类型的资源或具有何种访问级别。¶

例如，客户端可能只需要对用户 资源的“读取”访问权限，而不需要更新资源，因此客户端可以请求 授权服务器定义的只读作用域，并获取 无法用于更新资源的访问令牌。这需要 授权服务器、资源服务器和客户端之间进行协调。授权 服务器使客户端能够请求特定 作用域，并将这些作用域与颁发给客户端的访问令牌相关联。 然后，资源服务器负责在收到 有限作用域访问令牌时实施相应的作用域限制。¶

OAuth 不定义任何作用域值，而是由 授权服务器、OAuth 的扩展或配置文件来定义作用域。定义作用域的一个此类扩展 是 [OpenID.Connect]，它定义了一组 可提供对用户个人资料信息细粒度访问的作用域。 建议避免定义与已知扩展中的作用域相冲突的自定义作用域。¶

为了请求有限作用域的访问令牌，客户端根据 所使用的许可类型，在授权端点或令牌端点使用 scope 请求参数。相应地，授权服务器使用 scope 响应参数告知客户端所颁发访问令牌的作用域。¶

scope 参数的值表示为空格分隔的 区分大小写的字符串列表。这些字符串由 授权服务器定义。如果该值包含多个由空格分隔的 字符串，它们的顺序无关紧要，并且每个字符串都会为请求的作用域 增加一个额外的访问范围。¶

    scope       = scope-token *( SP scope-token )
    scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

授权服务器可以根据授权服务器策略或 资源所有者的指示，完全或部分忽略客户端请求的作用域。 如果所颁发访问令牌的作用域 与客户端请求的作用域不同，授权 服务器必须在令牌响应 （第 3.2.3 节）中包含 scope 响应参数，以告知 客户端实际授予的作用域。¶

如果客户端在请求授权时省略 scope 参数， 授权服务器必须使用预定义的默认值处理 请求，或者让请求失败并指明作用域无效。 授权服务器应该记录其作用域要求和默认值（如果已定义）。¶

1.4.2. 持有者令牌

持有者令牌是一种安全令牌，其属性是任何 持有该令牌的参与方（“持有者”）都能以 任何其他持有该令牌的参与方可以使用的方式使用该令牌。使用持有者令牌 不要求持有者证明其拥有密码学密钥材料 （持有证明）。¶

持有者令牌可以通过持有证明 规范得到增强，例如 DPoP [RFC9449] 和 mTLS [RFC8705]，从而提供 持有证明特性。¶

为了防止访问令牌泄露， 客户端与资源服务器之间的通信交互 必须使用第 1.5 节所述的 机密性和完整性保护。¶

持有者令牌的具体结构或格式没有要求。 如果持有者令牌是对授权信息的引用，则攻击者必须无法实际 猜出此类引用，例如使用足够长的 密码学随机字符串。如果持有者令牌使用编码机制将 授权信息包含在令牌本身中，则访问令牌必须使用 足以防止令牌被修改的完整性保护。访问令牌的 一种编码和签名机制在访问令牌的 JSON Web Token 配置文件 [RFC9068] 中进行了说明。¶

1.4.3. 发送方约束的访问令牌

发送方约束的访问令牌会将 访问令牌的使用绑定到特定发送方。该发送方必须 证明其知道某个秘密，作为接收方 （例如资源服务器）接受该访问令牌的前提条件。¶

授权服务器和资源服务器应该使用用于 对访问令牌施加发送方约束的机制，例如 OAuth 持有证明演示 （DPoP）[RFC9449] 或 OAuth 2.0 的相互 TLS [RFC8705]。 有关防止被盗和泄露的 访问令牌遭到滥用，请参阅 第 4.10.1 节（[RFC9700]）。¶

建议在客户端与 资源服务器之间使用端到端 TLS。如果 TLS 流量需要在中间方处终止， 请参阅 第 4.13 节（[RFC9700]）以获取进一步的安全建议。¶

1.7.1. 值的大小

本规范未定义 client_id、授权码、访问令牌、刷新令牌或 大多数其他协议参数的最大长度，因为这些值的长度取决于 颁发它们的一方所做的实现选择。在 实践中，实现会施加自己的限制，而超过 接收方实现限制的值将导致请求 失败。¶

实现不得假定其接收到的值适合 某个特定长度。颁发值的一方应该记录 其长度，并且应该考虑到将承载该值的组件的 限制。特别是，在重定向中返回的值， 例如授权码，会承载在 URI 查询字符串中，并且 HTTP 实现通常会限制请求行以及 单个标头字段的长度（第 3 节 （[RFC9112]）和 第 5.4 节（[RFC9110]））。 实现应该支持足够长的参数 值，以使请求保持在 第 3 节 （[RFC9112]）建议的 8000 个八位字节的 请求行长度以内。资源 服务器尤其不应该对访问令牌的长度施加过小限制， 因为结构化格式的令牌（例如 [RFC9068] 中定义的令牌）通常会超过一 千字节。¶

2.3.1. 注册 要求

授权服务器必须要求客户端注册其完整的 重定向 URI（包括路径组成部分）。授权服务器 必须拒绝指定了与已注册 URI 不 完全匹配的重定向 URI 的授权请求，但 环回重定向除外；对于环回重定向，除 端口 URI 组成部分之外，其余部分都要求完全匹配，详见第 4.1.1 节。¶

授权服务器可以允许客户端注册多个 重定向 URI。¶

注册可以在带外进行，例如在授权服务器处手动配置 客户端信息， 也可以在运行时进行，例如推送授权请求 [RFC9126] 中的初始 POST。¶

对于基于私有使用 URI 方案的重定向 URI，授权 服务器应该实施第 8.4.3 节中的要求，即客户端使用 基于反向域名的方案。至少，任何 不包含句点字符（.）的私有使用 URI 方案 都应该被拒绝。¶

除了抗冲突属性之外， 当两个应用声称使用同一私有使用 URI 方案 （其中一个应用具有恶意行为）发生争议时，这还有助于证明所有权。 例如，如果两个应用都声称使用 com.example.app， example.com 的所有者可以请求应用商店运营方 移除仿冒应用。如果使用的是 通用 URI 方案，则此类请求更难得到证明。¶

客户端不得暴露可将用户浏览器转发到 从查询参数获取的任意 URI 的 URL（“开放重定向器”），如 第 7.13 节所述。 开放重定向器可能导致 授权码和访问令牌被外泄。¶

如果需要，客户端可以使用 state 请求参数 实现每请求 自定义，而不是在每个请求中改变重定向 URI。¶

如果不要求注册重定向 URI，攻击者可以 将授权端点用作开放重定向器，如 第 7.13 节所述。¶

2.3.2. 多个重定向 URI

如果为客户端注册了多个重定向 URI，则 客户端必须在授权请求中使用 redirect_uri 请求参数包含一个重定向 URI（第 4.1.1 节）。 如果仅为客户端注册了一个重定向 URI， 则 redirect_uri 请求参数是可选的。¶

2.3.3. 防止 CSRF 攻击

客户端必须防止跨站请求伪造（CSRF）攻击。在此 上下文中，CSRF 指的是发送到重定向端点、但并非 源自授权服务器，而是源自恶意第三方的请求 （详见 第 4.4.1.8 节（[RFC6819]））。已经 确保授权服务器支持 code_challenge 参数的客户端可以 依赖该机制提供的 CSRF 保护。在 OpenID Connect 流程中， 验证 nonce 参数可提供 CSRF 保护。否则， 必须使用通过 state 参数携带并安全 绑定到用户代理的一次性 CSRF 令牌来提供 CSRF 保护（参见 第 7.10 节）。¶

2.3.4. 防止 混淆攻击

当 OAuth 客户端只能与一个授权 服务器交互时，不需要混淆防御。但是，在 OAuth 客户端与 两个或更多授权服务器交互的场景中，客户端必须防止混淆攻击。 为了防止混淆攻击，客户端只能处理与其发送相应请求的 发行者相对应的重定向响应，并且必须来自发起该 授权请求的同一个用户代理。¶

有关两种不同混淆攻击防御方式的详细说明，请参阅第 7.15 节。¶

2.3.5. 无效端点

如果授权请求由于缺少、 无效或不匹配的重定向 URI 而验证失败，授权服务器 应该告知资源所有者该错误，并且不得 自动将用户代理重定向到无效的重定向 URI。¶

2.3.6. 端点内容

发送到客户端端点的重定向请求通常会产生 一个由用户代理处理的 HTML 文档响应。如果 HTML 响应直接作为重定向请求的结果提供， HTML 文档中包含的任何脚本都将在可完全 访问重定向 URI 及其中所含工件（例如授权码）的情况下执行。 此外，包含授权码的请求 URL 可能会在 HTTP Referer 标头中发送给页面中加载的任何嵌入图像、样式表 和其他元素。¶

客户端不应该在重定向 URI 端点响应中包含任何第三方脚本（例如第三方 分析、社交插件、广告网络）。相反，它应该从 URI 中提取工件，并再次将用户代理重定向到另一个端点， 且不暴露这些工件（无论是在 URI 中还是其他位置）。如果包含第三方 脚本，客户端必须确保其自己的脚本 （用于从 URI 中提取并移除凭据） 首先执行。¶

2.4.1. 客户端密钥

为了支持拥有客户端密钥的机密客户端， 授权服务器必须支持客户端使用以下 参数在请求正文内容中包含客户端凭据：¶

"client_id":

必需。在 第 2.2 节所述注册过程中颁发给客户端的客户端标识符。¶

"client_secret":

必需。客户端密钥。¶

这些参数只能在请求内容中传输， 不得包含在请求 URI 中。¶

这也称为 client_secret_post，如 第 2 节（[RFC7591]）中所定义。¶

例如，使用内容参数刷新访问令牌（第 4.3 节）的请求 如下（仅为显示目的添加额外换行）：¶

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

授权服务器可以支持 HTTP Basic 认证方案，以认证已向其颁发 客户端密钥的客户端。¶

当使用 第 11 节（[RFC9110]） 定义的 HTTP Basic 认证方案 向授权服务器进行认证时，客户端标识符按照 附录 B使用 application/x-www-form-urlencoded 编码算法进行编码， 并将编码后的值用作用户名；客户端 密钥使用相同算法编码，并用作 密码。¶

这也称为 client_secret_basic，如 第 2 节（[RFC7591]）中所定义。¶

例如（仅为显示目的添加额外换行）：¶

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

注意：这种先对客户端标识符和密钥进行表单编码， 然后将编码后的值用作 HTTP Basic 认证用户名 和密码的方法，过去曾导致许多互操作性问题。一些 实现遗漏了编码步骤，或决定仅编码 某些字符，或在验证 凭据时忽略了编码要求，导致客户端不得不针对 不同授权服务器以特殊方式提交 凭据。将凭据包含在请求正文内容中可以避免编码问题，并实现 更具互操作性的实现。¶

由于客户端密钥认证方法涉及密码， 授权服务器必须保护任何使用该方法的端点免受 暴力破解攻击。¶

2.4.2. 其他 认证方法

授权服务器可以支持任何符合其安全要求的适当认证 方案。使用其他 认证方法时，授权服务器必须定义 客户端标识符（注册记录）与 认证方案之间的映射。¶

一些其他认证方法，例如 mTLS [RFC8705] 和私钥 JWT（[RFC7523]、 [I-D.ietf-oauth-rfc7523bis]） 定义在 “OAuth 令牌端点认证方法”注册表中， 并且可以用作通用客户端认证方法，而不仅限于 保护令牌端点这一特定用途。¶

3.2.1. 客户端 认证

机密客户端向令牌端点发出 请求时，必须按照 第 2.4 节所述向授权服务器 进行认证。¶

客户端认证用于：¶

• 强制将刷新令牌和 授权码绑定到它们所颁发给的 客户端。当授权码通过不安全通道传输到 重定向端点时，客户端认证增加了一层额外的安全保护。¶

• 通过禁用客户端或 更改其凭据，从客户端被攻破的情况中恢复，从而防止攻击者滥用 被盗的刷新令牌。更改单组客户端 凭据比撤销整组 刷新令牌快得多。¶

• 实施认证管理最佳实践， 这些实践要求定期轮换凭据。轮换整组 刷新令牌可能很困难，而轮换单组 客户端凭据则容易得多。¶

3.2.2. 令牌端点 请求

客户端通过使用 附录 C.2规定的表单编码序列化 格式，并在 HTTP 请求内容中采用 UTF-8 字符编码发送以下参数，来向令牌端点发出请求：¶

"grant_type":

必需。客户端在特定令牌请求中使用的 许可类型标识符。 本规范定义了值 authorization_code、 refresh_token 和 client_credentials。 许可类型决定令牌请求需要或支持的 其他参数。这些许可类型的 详细信息在下文定义。¶

"client_id":

可选。当使用依赖该参数的 客户端认证形式，或者 grant_type 要求 识别公共客户端时，需要客户端标识符。¶

机密客户端必须按照第 3.2.1 节所述向授权 服务器进行认证。¶

例如，客户端发出以下 HTTPS 请求 （仅为显示目的添加额外换行）：¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

授权服务器必须：¶

• 要求机密客户端 （或具有其他认证要求的客户端）进行客户端认证，¶

• 如果包含客户端认证，则 认证客户端¶

还适用其他特定于许可类型的处理规则，这些规则在相应的 许可类型中规定。¶

3.2.3. 令牌端点 响应

如果访问令牌请求有效且已获授权， 授权服务器将颁发访问令牌以及可选的刷新 令牌。¶

如果客户端认证失败或无效，授权 服务器将返回第 3.2.4 节中所述的错误响应。¶

授权服务器按照附录 C.3创建 HTTP 响应， 使用 [RFC8259]定义的 application/json 媒体类型， 并包含以下参数及 HTTP 200（OK）状态码， 以颁发访问令牌以及可选的刷新令牌：¶

"access_token":

必需。授权 服务器颁发的访问令牌。¶

"token_type":

必需。按照 第 1.4 节所述颁发的访问令牌类型。该值 不区分大小写。¶

"expires_in":

建议。一个表示访问令牌生命周期（以秒为单位）的 JSON 数字。例如，值 3600 表示访问令牌将在 响应生成后的一小时过期。 如果省略，授权服务器应该通过其他方式提供该 生命周期，或者记录默认值。请注意， 授权服务器可能会提前使访问 令牌过期，因此客户端不得期望访问令牌在所提供的 生命周期内始终有效。¶

"scope":

如果与客户端请求的作用域相同，则建议包含； 否则为必需。访问令牌的作用域，如 第 1.4.1 节所述。¶

"refresh_token":

可选。刷新令牌，可用于 根据相应令牌请求中传递的许可 获取新的访问令牌。¶

授权服务器应该根据风险评估 以及其自身策略，决定是否向某个客户端颁发刷新令牌。如果 授权服务器决定不颁发刷新令牌，客户端 可以通过重新开始 OAuth 流程来获取新的访问令牌，例如 发起新的授权码请求。在这种情况下，授权 服务器可以利用 Cookie 和持久许可来优化用户 体验。¶

如果颁发刷新令牌，这些刷新令牌必须绑定到 资源所有者同意的作用域和资源服务器。 这是为了防止合法客户端提升权限，并 降低刷新令牌泄露的影响。¶

这些参数按照附录 C.3中的说明序列化为 JavaScript Object Notation （JSON） 结构。¶

授权服务器在任何 包含令牌、凭据或其他敏感 信息的响应中，都必须包含 HTTP Cache-Control 响应标头字段（参见 第 5.2 节（[RFC9111]）），其值为 no-store。¶

例如：¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter": "example_value"
}

客户端必须忽略响应中无法识别的值名称。 从授权服务器接收到的令牌及其他值的长度 保持未定义，如第 1.7.1 节所述。¶

3.2.4. 令牌端点 错误响应

授权服务器使用 HTTP 400（错误请求） 状态码进行响应（除非另有规定），并在响应中包含以下 参数：¶

"error":

必需。以下错误代码之一的单个 ASCII [USASCII] 值：¶

"invalid_request":

请求缺少必需参数、 包含不支持的参数值（许可类型除外）、 重复某个参数、包含多个凭据、 使用一种以上机制来认证 客户端、虽然授权请求中未发送 code_challenge 却包含 code_verifier， 或者以其他方式格式错误。¶

"invalid_client":

客户端认证失败（例如未知 客户端、未包含客户端认证或不支持的 认证方法）。授权服务器可以 返回 HTTP 401（未授权）状态码，以指明 支持哪些 HTTP 认证方案。如果 客户端尝试通过 Authorization 请求标头字段进行认证，则授权服务器必须 使用 HTTP 401（未授权）状态码进行响应，并 包含与客户端所使用认证方案相匹配的 WWW-Authenticate 响应标头字段。¶

"invalid_grant":

所提供的授权许可（例如 授权码、资源所有者凭据）或刷新令牌 无效、已过期、已撤销、与授权请求中使用的 重定向 URI 不匹配，或颁发给了 另一个客户端。¶

"unauthorized_client":

已认证的客户端无权 使用此授权许可类型。¶

"unsupported_grant_type":

授权服务器不支持该 授权许可类型。¶

"invalid_scope":

请求的作用域无效、未知、 格式错误，或 超出了资源所有者授予的作用域。¶

error 参数的值不得 包含集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符。¶

"error_description":

可选。人类可读的 ASCII [USASCII] 文本，用于提供 附加信息，以帮助客户端开发者 理解所发生的错误。 error_description 参数的值不得包含 集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符。¶

"error_uri":

可选。一个标识人类可读网页的 URI， 该网页包含有关错误的信息，用于向客户端 开发者提供有关错误的附加信息。 error_uri 参数的值必须符合 URI-reference 语法，因此不得包含 集合 %x21 / %x23-5B / %x5D-7E 之外的字符。¶

这些参数使用附录 C.3中定义的 application/json 媒体类型包含在 HTTP 响应内容中。¶

例如：¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
 "error": "invalid_request"
}

4.1.1. 授权 请求

为了开始授权请求，客户端通过向授权服务器的 授权端点 URI 添加参数来构建 授权请求 URI。客户端最终会将用户代理重定向 到此 URI 以发起请求。¶

客户端为每个 授权请求使用一个称为“代码验证器”的唯一秘密，以防止授权码 注入和 CSRF 攻击。客户端首先生成代码验证器，然后派生 要包含在授权请求中的“代码质询”。客户端 在令牌端点交换授权码时使用代码验证器，以 证明使用该 授权码的客户端就是请求该授权码的同一个客户端。¶

客户端按照附录 C.1所述，通过向授权端点 URI 的查询组成部分添加以下 参数来构造请求 URI：¶

"response_type":

必需。授权端点支持不同的 请求和响应参数集合。客户端通过使用特定的 response_type 值来确定流程类型。本规范定义了值 code，必须使用该值来表示 客户端希望使用授权码流程。¶

扩展响应类型可以包含以空格分隔（%x20）的 值列表，其中值的顺序无关紧要（例如，响应 类型 a b 与 b a 相同）。此类复合 响应类型的含义由相应规范定义。¶

一些扩展响应类型由 [OpenID.Connect] 定义。¶

如果授权请求缺少 response_type 参数， 或者无法理解该响应类型，授权服务器 必须返回第 4.1.2.1 节所述的错误响应。¶

"client_id":

必需。第 2.2 节所述的客户端标识符。¶

"code_challenge":

必需，除非满足第 7.5.1 节中的特定要求。 从代码验证器派生的代码质询。¶

"code_challenge_method":

必需，值为 S256 或未来扩展定义的值¶

"redirect_uri":

如果仅为此客户端注册了一个重定向 URI，则为可选。 如果为此客户端注册了多个重定向 URI，则为必需。 参见第 2.3.2 节。¶

"scope":

可选。访问请求的作用域，如 第 1.4.1 节所述。¶

"state":

可选。客户端用于在请求和回调之间 保持 状态的不透明值。授权 服务器在将用户代理重定向回 客户端时包含此值。该值被携带在 授权请求 URI 的查询组成部分中，并在重定向回 客户端时再次携带，因此其长度实际上受授权服务器、 用户代理和客户端所接受的 URI 和 HTTP 标头字段长度限制；参见第 1.7.1 节。¶

code_verifier 是为 每个授权请求生成的唯一高熵 密码学随机字符串，使用非保留字符 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"， 最小长度为 43 个字符，最大长度为 128 个字符。¶

客户端临时存储 code_verifier，并 计算其在授权请求中使用的 code_challenge。¶

code_verifier 的 ABNF 如下。¶

code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

客户端必须使用不会在授权请求中 暴露 code_verifier 的代码质询方法。 否则，能够读取授权请求的攻击者（参见 [RFC9700] 中的攻击者 A4）可以 破坏该机制提供的安全性。目前，S256 是唯一此类方法。¶

注意：代码验证器应该具有足够的熵，以使 猜测该值在实践中不可行。建议使用 合适的随机数生成器的输出来创建一个 32 个八位字节的 序列。然后对该八位字节序列进行 base64url 编码，以生成一个 43 个八位字节的 URL 安全字符串，用作代码验证器。¶

然后，客户端通过使用有效的转换方法转换代码验证器， 创建从代码 验证器派生的 code_challenge：¶

S256
  code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

本规范仅定义 S256 转换。未来扩展 可以定义其他转换方法。¶

code_challenge 的 ABNF 如下。¶

code-challenge = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

code_challenge 和 code_verifier 属性采用自被称为“代码交换证明密钥” （Proof-Key for Code Exchange，PKCE）的 OAuth 2.0 扩展 [RFC7636]，该技术最初在其中 开发。本规范移除了 [RFC7636] 中定义的 plain 转换方法，并明确禁止使用该方法。有关更多详细信息，请参阅第 7.5.2 节。¶

授权服务器必须支持 code_challenge 和 code_verifier 参数。¶

客户端必须使用 code_challenge 和 code_verifier，并且 授权服务器必须强制使用它们，除非符合 第 7.5.1 节所述的条件。即使在这种情况下，仍然建议按上述方式使用并强制执行 code_challenge 和 code_verifier。¶

state 和 scope 参数不应该 以明文形式包含敏感的 客户端或资源所有者信息，因为它们可能通过 不安全的通道传输或以不安全的方式存储。¶

客户端使用 HTTP 重定向，或通过用户代理可用的其他方式，将资源所有者引导至构造的 URI。¶

例如，客户端引导用户代理发出以下 HTTPS 请求（仅为显示目的添加额外换行）：¶

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
    &code_challenge=6fdkQaPm51l13DSukcAH3Mdx7_ntecHYd1vi3n0hMZY
    &code_challenge_method=S256 HTTP/1.1
Host: server.example.com

授权服务器验证请求，以确保所有 必需参数均存在且有效。¶

特别是，如果请求中存在 redirect_uri，授权服务器必须对其进行验证， 确保它与客户端注册期间先前建立的已注册 重定向 URI 之一相匹配（第 2 节）。 比较两个 URI 时，授权服务器必须确保 两个 URI 相等，详见 第 6.2.1 节（[RFC3986]）中的简单字符串比较。 唯一例外是使用 localhost URI 的原生应用：在这种情况下，授权 服务器 必须允许可变端口号，如第 8.4.2 节所述。¶

如果请求有效， 授权服务器会认证资源所有者，并获得 授权决定（通过询问资源所有者或 通过其他方式确定批准）。¶

确定决定后，授权服务器使用 HTTP 重定向响应，或通过 用户代理可用的其他方式，将 用户代理引导至所提供的客户端重定向 URI。¶

4.1.2. 授权 响应

如果资源所有者授予访问请求，授权 服务器会颁发授权码，并通过 使用附录 C.1所述的查询字符串序列化， 将以下参数添加到 重定向 URI 的查询组成部分中来将其交付给客户端， 除非扩展另有规定：¶

"code":

必需。授权码由 授权服务器生成，并且对客户端是不透明的。授权码必须在 颁发后很快过期，以降低泄露风险。建议 授权码的最大生命周期为 10 分钟。 授权码绑定到 客户端标识符、代码质询和重定向 URI。¶

"state":

如果客户端授权请求中存在 state 参数， 则为必需。其值必须与从 客户端收到的值完全相同。¶

"iss":

必需。授权 服务器的发行者标识符，如果客户端与 多个授权服务器交互，客户端可以使用它来防止混淆攻击。有关客户端如何使用它防止混淆攻击的 更多详细信息，请参阅第 7.15 节和 [RFC9207]。¶

例如，授权服务器通过 发送以下 HTTP 响应来重定向用户代理：¶

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz&iss=https%3A%2F%2Fauthorization-server.example.com

客户端必须忽略无法识别的响应参数。 授权码字符串的长度由本 规范保持未定义，如第 1.7.1 节所述。¶

授权服务器必须将 code_challenge 和 code_challenge_method 值与所颁发的授权码相关联， 以便稍后验证代码质询。¶

服务器用于将 code_challenge 与所颁发代码相关联的确切方法超出本规范的范围。 代码质询可以存储在服务器上，并在那里与 代码相关联。code_challenge 和 code_challenge_method 值可以 以加密形式存储在代码本身中，但服务器 不得在响应参数中以 AS 以外的实体 能够提取的形式包含 code_challenge 值。¶

客户端必须防止攻击者将授权码注入（重放）到 授权响应中。使用 code_challenge 和 code_verifier 可以防止授权码注入，因为 授权服务器会拒绝 code_verifier 不匹配的令牌请求。 有关更多详细信息，请参阅第 7.5.1 节。¶

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied
          &state=xyz&iss=https%3A%2F%2Fauthorization-server.example.com

4.1.3. 令牌端点 扩展

授权许可类型在令牌端点通过 grant_type 值 authorization_code 来标识。¶

如果设置了此值，则支持第 3.2.2 节之外的以下附加令牌请求 参数：¶

"code":

必需。从 授权服务器接收到的授权码。¶

"code_verifier":

如果授权 请求中包含 code_challenge 参数，则为必需。否则不得使用。原始代码验证器字符串。¶

"client_id":

如果客户端未按照第 3.2.1 节所述向 授权服务器进行认证，则为必需。¶

对于给定的授权码，授权服务器必须只返回一次访问令牌。¶

如果使用与先前成功令牌请求相同的 授权码发出了第二个有效令牌请求， 授权服务器必须拒绝该请求，并且应该 撤销（如果可能）此前基于该授权码颁发的所有访问令牌和刷新令牌。 有关更多详细信息，请参阅第 7.5.3 节。¶

例如，客户端发出以下 HTTPS 请求 （仅为显示目的添加额外换行）：¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

除第 3.2.2 节中的处理规则之外，授权服务器还必须：¶

• 确保授权码是颁发给经过认证的 机密 客户端的，或者如果客户端是公共客户端，则确保该 代码是颁发给请求中的 client_id 的，¶

• 验证授权码有效，¶

• 当且仅当授权 请求中存在 code_challenge 参数时，验证 code_verifier 参数是否存在，¶

• 如果存在 code_verifier，则通过根据客户端指定的 code_challenge_method 方法首先对其进行转换，然后根据收到的 code_verifier 计算 代码质询，并将其 与先前关联的 code_challenge 进行比较，从而验证 code_verifier，以及¶

• 如果与令牌请求中的授权码相关联的 授权请求中没有 code_challenge， 授权服务器必须 拒绝该令牌请求。¶

有关令牌请求中的 redirect_uri 参数与 OAuth 2.0 客户端 向后兼容的详细信息，请参阅第 10.2 节。¶

4.2.1. 令牌端点 扩展

客户端凭据许可类型在令牌 端点通过 grant_type 值 client_credentials 来标识。¶

如果设置了此值，则支持第 3.2.2 节之外的以下附加令牌请求 参数：¶

"scope":

可选。访问请求的作用域，如 第 1.4.1 节所述。¶

例如，客户端使用 传输层安全发出以下 HTTP 请求（仅为显示目的添加额外换行）：¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

授权服务器必须认证客户端。¶

4.3.1. 令牌端点 扩展

刷新令牌许可类型在令牌端点 通过 grant_type 值 refresh_token 来标识。¶

如果设置了此值，则支持第 3.2.2 节之外的以下附加参数：¶

"refresh_token":

必需。颁发给客户端的刷新令牌。¶

"scope":

可选。访问请求的作用域，如 第 1.4.1 节所述。请求的作用域不得包含 最初未由资源所有者授予的任何作用域，如果省略， 则视为等于资源所有者最初授予的 作用域。¶

由于刷新令牌通常是用于 请求其他访问令牌的长期凭据，因此刷新令牌会绑定到 其所颁发给的客户端。机密客户端 必须按照第 3.2.1 节所述向授权服务器进行认证。¶

例如，客户端使用 传输层安全发出以下 HTTP 请求（仅为显示目的添加额外换行）：¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

除第 3.2.2 节中的处理规则之外，授权服务器还必须：¶

• 如果请求中包含客户端认证， 确保刷新令牌颁发给了经过认证的客户端，或者如果请求中包含 client_id，则确保刷新令牌颁发给了 匹配的客户端¶

• 验证与此刷新 令牌相对应的许可仍处于活动状态¶

• 验证刷新令牌¶

对于公共客户端，授权服务器必须使用以下方法之一来检测 恶意行为者对刷新令牌的重放：¶

• 发送方约束的刷新令牌：授权 服务器 以密码学方式将刷新令牌绑定到某个客户端 实例，例如通过使用 DPoP [RFC9449] 或 mTLS [RFC8705]。¶

• 刷新令牌轮换：授权 服务器在每次访问令牌刷新响应中颁发新的 刷新令牌。先前的刷新令牌会失效，但有关 两者关系的信息由授权服务器保留。如果 刷新令牌被泄露，并随后由攻击者和合法客户端 同时使用，其中一方将提交一个 已失效的刷新令牌，从而告知授权 服务器发生了泄露。授权服务器无法确定 哪一方提交了无效刷新令牌，但它会 撤销活动刷新令牌以及与之关联的访问授权 许可。这会阻止攻击， 代价是迫使合法客户端获取新的 授权许可。¶

实现说明：刷新令牌所属的许可 可以编码到刷新令牌本身中。这可以使 授权服务器高效确定刷新令牌所属的许可， 进而确定所有需要撤销的刷新令牌。 在这种情况下，授权服务器必须确保 刷新令牌值的完整性，例如 使用签名。¶

4.3.2. 刷新令牌 响应

如果有效且已获授权，授权服务器将按照第 3.2.3 节所述颁发访问 令牌。¶

授权服务器可以颁发新的刷新令牌，在这种 情况下， 客户端必须丢弃旧刷新令牌，并将其替换为 新刷新令牌。¶

4.3.3. 刷新令牌 建议

授权服务器在向客户端颁发新的刷新令牌后，可以撤销旧的 刷新令牌。如果 颁发了新的刷新令牌，则其作用域必须与客户端在 请求中包含的刷新令牌的作用域 完全相同。¶

发生安全事件时，授权服务器可以自动撤销刷新令牌，例如：¶

• 密码更改¶

• 在授权服务器注销¶

如果客户端已闲置一段 时间，即刷新令牌已有一段时间未用于获取新的 访问令牌，则刷新令牌应该过期。到期时间由 授权服务器自行决定。它可以是一个全局值， 也可以根据客户端策略或与 刷新令牌关联的许可（及其敏感性）来确定。¶

5.1.1. Authorization 请求标头字段

在 HTTP/1.1 [RFC7235] 定义的 Authorization 请求标头 字段中发送访问令牌时，客户端使用 Bearer 方案传输访问令牌。¶

例如：¶

 GET /resource HTTP/1.1
 Host: server.example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

此方案的 Authorization 标头字段语法 遵循 第 2 节 （[RFC2617]）中定义的 Basic 方案用法。 请注意，与 Basic 一样，它不符合 第 1.2 节（[RFC2617]）中定义的通用语法，但与 HTTP 1.1 认证 [RFC7235] 中的通用认证框架兼容，尽管为了反映现有部署， 它没有遵循其中概述的首选 实践。 Bearer 凭据的语法如下：¶

token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "bearer" 1*SP token68

客户端应该使用带有 Bearer HTTP 授权方案的 Authorization 请求标头字段，以持有者令牌发出经过认证的请求。 资源服务器必须支持此方法。¶

如 第 11.1 节（[RFC9110]）所述， 字符串 bearer 不区分大小写。这意味着以下所有用法都是 Authorization 标头的有效用法：¶

• Authorization: Bearer mF_9.B5f-4.1JqM¶

• Authorization: bearer mF_9.B5f-4.1JqM¶

• Authorization: BEARER mF_9.B5f-4.1JqM¶

• Authorization: bEaReR mF_9.B5f-4.1JqM¶

5.1.2. 表单编码 内容参数

在 HTTP 请求内容中发送访问令牌时， 客户端使用 access_token 参数将访问令牌添加到请求内容中。除非 满足以下所有条件，否则客户端不得使用此方法：¶

• HTTP 请求包含设置为 application/x-www-form-urlencoded 的 Content-Type 标头 字段。¶

• 内容遵循 URL 现行标准 [WHATWG.URL] 定义的 application/x-www-form-urlencoded 内容类型的编码要求。¶

• HTTP 请求内容为单部分。¶

• 请求中要编码的内容必须完全 由 ASCII [USASCII] 字符组成。¶

• HTTP 请求方法必须是其内容具有 已定义语义的方法。特别是，这意味着不得使用 GET 方法。¶

内容可以包含其他特定于请求的参数，在 这种情况下，必须使用 & 字符（ASCII 代码 38）将 access_token 参数与特定于请求的参数正确分隔。¶

例如，客户端使用 传输层安全发出以下 HTTP 请求：¶

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

除非应用程序上下文中的参与客户端无法 访问 Authorization 请求标头字段，否则不应该 使用 application/x-www-form-urlencoded 方法。资源 服务器可以支持此方法。¶

5.3.1. WWW-Authenticate 响应标头字段

如果受保护资源请求不包含认证 凭据，或者不包含能够访问 受保护资源的访问令牌，则资源服务器必须包含 HTTP WWW-Authenticate 响应标头字段；它也可以在 响应其他条件时包含该字段。WWW-Authenticate 标头 字段使用 HTTP/1.1 [RFC7235] 定义的框架。¶

此令牌类型的所有质询都必须使用 auth-scheme 值 Bearer。此方案后面必须跟随一个或多个 auth-param 值。本 规范为此令牌类型使用或定义的 auth-param 属性如下。也可以使用其他 auth-param 属性。¶

"realm":

可以包含 realm 属性，以 按照 HTTP/1.1 [RFC7235] 中所述的方式指明 保护范围。 realm 属性不得出现多次。¶

"scope":

scope 属性在第 1.4.1 节中定义。 scope 属性是以空格分隔的区分大小写的作用域 值列表，用于指明访问所请求资源时 访问令牌所需的作用域。scope 值由实现 定义；不存在集中式注册表；允许的值 由授权服务器定义。scope 值的顺序 无关紧要。在某些情况下，scope 值会在请求 具有足够访问作用域、可以使用受保护资源的新访问令牌时使用。 scope 属性的使用是 可选的。scope 属性不得出现多次。 scope 值旨在供程序使用，不应 显示给最终用户。¶

下面给出两个示例作用域值；它们分别取自 OpenID Connect [OpenID.Messages] 和开放 认证技术 委员会（OATC）在线多媒体授权协议 [OMAP] 的 OAuth 2.0 用例：¶

scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

¶

"error":

如果受保护资源请求包含访问 令牌但认证失败，资源服务器应该包含 error 属性，以向客户端提供访问 请求被拒绝的原因。参数值在 第 5.3.2 节中说明。¶

"error_description":

资源服务器可以包含 error_description 属性，为开发者提供人类可读的 说明，该说明并非用于向最终用户显示。¶

"error_uri":

资源服务器可以包含 error_uri 属性，其值是一个绝对 URI， 用于标识解释该错误的人类可读网页。¶

error、error_description 和 error_uri 属性均不得 出现多次。¶

scope 属性的值（在附录 A.4中规定） 不得包含用于表示作用域值的集合 %x21 / %x23-5B / %x5D-7E 以及用于 作用域值之间分隔符的 %x20 之外的字符。error 和 error_description 属性的值（分别在附录 A.7和附录 A.8中规定）不得 包含集合 %x20-21 / %x23-5B / %x5D-7E 之外的字符。 error_uri 属性的值（在附录 A.9中规定） 必须符合 URI-reference 语法，因此不得 包含集合 %x21 / %x23-5B / %x5D-7E 之外的字符。¶

5.3.2. 错误代码

当请求失败时，资源服务器使用适当的 HTTP 状态码（通常为 400、401、403 或 405）进行响应，并 在响应中包含以下错误代码之一：¶

"invalid_request":

请求缺少必需参数、包含 不支持的参数或参数值、重复相同的 参数、使用一种以上的方法包含访问 令牌，或者存在其他格式错误。资源服务器应该 使用 HTTP 400（错误请求）状态码进行响应。¶

"invalid_token":

所提供的访问令牌已过期、已撤销、 格式错误或 因其他原因无效。资源服务器应该使用 HTTP 401（未授权）状态码进行响应。客户端可以 请求新的访问令牌并重试受保护资源 请求。¶

"insufficient_scope":

请求所需的权限（作用域）高于 授予客户端并由访问令牌表示的 作用域所提供的权限。 资源服务器应该使用 HTTP 403（禁止）状态码进行响应，并且可以包含 scope 属性，其中包含访问受保护 资源所需的作用域。¶

扩展可以定义其他错误代码，或者指定返回上述错误代码的其他 情形。¶

如果请求缺少任何认证信息（例如， 客户端 不知道需要认证，或尝试使用 不受支持的认证方法），资源服务器不应该 包含错误代码或其他错误信息。¶

例如：¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

而对于使用已过期访问令牌尝试 认证的受保护资源请求，则响应如下：¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="访问令牌已过期"

6.1.1. 已注册的 访问令牌类型

[RFC6750] 在 第 11.4 节（[RFC6749]） 中建立了一个通用注册表，用于在 OAuth 令牌认证方案之间共享错误值。¶

主要为 OAuth 令牌 认证设计的新认证方案应该定义一种向客户端提供错误 状态码的机制，其中允许的错误值 注册在本规范建立的错误注册表中。¶

此类方案可以将有效错误代码集限制为 已注册值的子集。如果错误代码使用命名 参数返回，则参数名称应该是 error。¶

其他能够用于 OAuth 令牌认证， 但并非主要为此目的设计的方案，也可以以相同方式将其错误 值绑定到该注册表。¶

新认证方案还可以选择规定使用 error_description 和 error_uri 参数，以与本 规范中的用法类似的方式返回错误 信息。¶

类型名称必须符合 type-name ABNF。如果类型定义包含新的 HTTP 认证方案，则类型名称应该与 HTTP 认证方案名称（如 [RFC2617] 所定义）相同。令牌类型 example 保留用于示例。¶

type-name  = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

6.1.2. 供应商特定的访问令牌类型

使用 URI 名称的类型应该仅限于 不具有普遍适用性的供应商特定实现，并且特定于 使用它们的资源服务器的实现细节。¶

所有其他类型都必须注册。¶

7.1.1. 安全威胁

以下列表列出了针对使用某种形式令牌的协议的若干常见威胁。 此威胁列表基于 NIST 特别出版物 800-63 [NIST800-63]。¶

7.1.2. 威胁缓解

通过使用数字签名保护访问令牌的内容，并遵循 签名密钥管理的最佳实践（例如定期轮换密钥），可以缓解大量威胁。¶

或者，持有者令牌可以包含对 授权信息的引用，而不是直接编码该信息。 使用引用可能需要资源服务器与授权服务器之间进行一次额外交互， 以将该引用解析为 授权信息。此类交互的机制 未由本规范定义，但令牌内省 [RFC7662] 定义了其中一种机制。¶

本文档未规定访问令牌的编码或内容； 因此，有关保证访问令牌完整性保护手段的详细建议 超出本 规范的范围。访问令牌的一种编码和 签名机制在 访问令牌的 JSON Web Token 配置文件 [RFC9068] 中进行了说明。¶

为了应对访问令牌重定向，授权 服务器在令牌中包含预期接收方（即 受众）的身份非常重要，通常是单个资源服务器（或资源 服务器列表）。还建议将令牌的使用限制在 特定作用域内。¶

第 1.5 节提供了有关 防止访问令牌泄露，以及为 客户端、资源服务器和授权服务器之间的通信 提供机密性和完整性的信息。¶

7.1.3. 建议 摘要

7.1.4. 访问令牌 权限限制

与访问令牌关联的权限应该限制为 特定应用程序或用例所需的最低权限。 这可防止客户端超出资源所有者授权的 权限。它还可防止用户超出相应安全策略 所授权的权限。权限 限制还有助于减小访问令牌泄露的影响。¶

特别是，访问令牌应该限制到某些 资源服务器（受众限制），最好限制到单个资源 服务器。为实现这一点，授权服务器将 访问令牌与某些资源服务器关联，并且每个资源 服务器都有义务针对每个请求验证随该请求发送的访问 令牌是否旨在用于该特定 资源服务器。如果不是，资源服务器必须拒绝处理 相应请求。客户端和授权服务器可以分别 使用本文档和 [RFC8707] 中规定的 scope 或 resource 参数， 以 确定它们希望访问的资源服务器。¶

此外，访问令牌应该限制到资源服务器上的某些 资源 和操作，或某些资源上的操作。为实现这一点， 授权服务器将访问令牌与相应资源和操作 相关联，并且每个资源服务器都有义务 针对每个请求验证随该请求发送的访问令牌是否旨在用于 该特定资源上的特定操作。如果不是，资源服务器必须拒绝 处理相应请求。客户端和授权服务器可以 使用参数 scope 以及 [RFC9396] 中规定的 authorization_details 来 确定这些资源和/或操作。¶

7.3.1. 冒充 原生应用

如上所述，授权 服务器不应该在没有用户同意或交互的情况下自动处理授权请求， 除非能够确认 客户端的身份。这包括用户 先前已经批准针对给定客户端 ID 的授权请求的情况—— 除非可以证明客户端的身份，否则该请求应该 按照此前没有批准过任何请求来处理。¶

授权服务器可以接受诸如声明的 https 方案重定向之类的措施作为 身份证明。 某些操作系统可能 提供其他平台特定的身份功能，在适当情况下也可以 接受这些功能。¶

7.3.2. 访问令牌 权限限制

客户端应该请求具有所需最小作用域的访问令牌。 授权服务器在决定如何满足所请求的作用域时应该考虑客户端身份， 并且可以 颁发作用域少于所请求作用域的访问令牌。¶

与访问令牌关联的权限应该限制为 特定应用程序或用例所需的最低权限。这 可防止客户端超出资源所有者授权的 权限。它还可防止用户超出相应安全策略 授权的权限。权限限制 还有助于减小访问令牌泄露的影响。¶

特别是，访问令牌应该限制到某些 资源服务器（受众限制），最好限制到单个资源 服务器。为实现这一点，授权服务器将 访问令牌与某些资源服务器相关联，并且每个资源 服务器都有义务针对每个请求验证随该请求发送的访问 令牌是否旨在用于该特定 资源服务器。如果不是，资源服务器必须拒绝处理 相应请求。客户端和授权服务器可以分别使用 [RFC8707] 中规定的 参数 scope 或 resource，以 确定它们希望访问的资源服务器。¶

7.5.1. 授权 码注入

授权码注入是一种攻击，其中客户端在其重定向 URI 中接收到 来自攻击者的授权码，而不是来自合法授权服务器的授权 码。如果没有适当保护机制，客户端便没有 任何机制知道攻击已经发生。授权 码注入既可能导致攻击者获得对受害者账户的访问权限，也 可能导致受害者意外获得对攻击者账户的访问权限。¶

7.5.2. PKCE "plain" 代码质询方法

[RFC7636] 中定义的 plain 代码质询方法，在 OAuth 2.1 中被明确禁止。 对于能够读取授权请求的攻击者 （[RFC9700] 中的攻击者 A4），plain 方法无法提供针对授权 码拦截的任何保护，因为代码验证器会以 明文形式在授权请求中传输。¶

支持 plain 模式的历史理由（设备缺少 密码学哈希能力）已经因 OAuth 2.1 对 TLS 1.2+ 的要求而过时， 因为后者要求支持 SHA-256 以进行证书验证。任何能够 实现 OAuth 2.1 的设备都必然支持 SHA-256。¶

支持 plain 代码质询 方法的授权服务器会产生一个 无法验证的降级攻击向量，因为服务器无法区分合法的 受限客户端与声称受限但被攻击者修改过的请求。¶

对于存在无法支持 S256 的现有客户端的部署，在停止支持旧版 授权方法之前应该 颁发延长生命周期的刷新令牌，因为刷新令牌许可（第 4.3 节） 不要求 PKCE。¶

7.5.3. 重用 授权码

如果授权码能够被 使用一次以上，则可能发生多种类型的攻击。¶

如第 4.1.3 节所述，当收到一个此前已经用于 颁发访问令牌的授权码的第二个有效请求时，授权服务器必须拒绝 该令牌请求，并撤销任何已颁发的令牌。如果攻击者能够外泄授权码 并在合法客户端之前使用它，攻击者将获得访问令牌， 而合法客户端则不会。撤销所有已颁发的令牌意味着攻击者的 令牌随后也会被撤销，从而阻止攻击继续进行。¶

但是，授权服务器只有在 包含授权码的请求本身也有效，包括 code_verifier 和客户端认证等所有其他参数 都有效时，才应该撤销已颁发的令牌。授权 服务器在收到包含无效参数的重放授权码时 不应该撤销任何已颁发的令牌。如果这样做， 那么能够获得授权码但无法获得客户端认证信息或 code_verifier 的攻击者 就可以在合法客户端之前发送无效的 授权码请求，并在合法客户端发出有效请求时使其 令牌被撤销，从而造成拒绝服务 的机会。¶

7.5.4. HTTP 307 重定向

重定向可能包含用户 凭据的请求的授权服务器不得使用 307 状态码（第 15.4.8 节（[RFC9110]））进行 重定向。 如果对此类请求使用 HTTP 重定向（而不是例如 JavaScript），AS 应该使用状态 码 303（“See Other”）。¶

在授权端点，典型的协议流程是 AS 提示用户在表单中输入其凭据，然后 将该表单（使用 POST 方法）提交回授权 服务器。AS 检查凭据，如果成功，则将 用户代理重定向到客户端的重定向 URI。¶

如果使用状态码 307 进行重定向，用户代理 会通过 POST 请求将用户凭据发送给客户端。¶

这会将敏感凭据泄露给客户端。如果 客户端是恶意的，它可以使用这些凭据在 AS 上冒充 用户。¶

这种行为对开发者而言可能出乎意料，但它在 第 15.4.8 节（[RFC9110]）中有明确定义。该 状态码不要求用户代理 将 POST 请求重写为 GET 请求，从而丢弃 POST 请求内容中的表单数据。¶

在 HTTP [RFC9110] 中，只有状态码 303 明确强制将 HTTP POST 请求重写为 HTTP GET 请求。对于包括常用的 302 在内的所有其他状态码，用户 代理都可以选择不将 POST 重写为 GET 请求，因此 可能将用户凭据泄露给客户端。（不过在实践中， 大多数用户代理只会对 307 重定向表现出这种行为。）¶

7.13.1. 客户端作为开放 重定向器

客户端不得暴露开放重定向器。攻击者可能使用开放 重定向器生成指向客户端的 URL，并利用它们 外泄授权码，如 第 4.1.1 节（[RFC9700]）所述。 另一种滥用方式是生成看似指向客户端的 URL。 这可能诱骗用户信任该 URL 并在浏览器中访问它。 这可以被滥用于网络钓鱼。¶

为了防止开放重定向，客户端应该仅在 目标 URL 已列入白名单，或者能够认证请求的来源和完整性时才进行重定向。 OWASP [owasp_redir] 描述了针对开放重定向的对策。¶

7.13.2. 授权 服务器作为开放重定向器

与客户端一样，攻击者也可能试图利用用户对 授权服务器（尤其是其 URL）的信任来实施 网络钓鱼攻击。OAuth 授权服务器经常将用户重定向 到其他网站（客户端），但必须安全地执行此操作。¶

第 4.1.2.1 节已经通过规定在 client_id 和 redirect_uri 组合无效的情况下， 授权服务器不得自动重定向用户代理， 从而防止开放重定向。¶

但是，攻击者也可以利用正确注册的 重定向 URI 来实施网络钓鱼攻击。例如，攻击者可以通过动态客户端注册 [RFC7591] 注册客户端，并执行以下攻击之一：¶

1. 故意发送错误的授权请求， 例如 使用无效作用域值，从而指示授权服务器将 用户代理重定向到其网络钓鱼网站。¶

2. 故意发送一个有效的授权请求，其中 client_id 和 redirect_uri 由攻击者控制。用户完成认证后， 授权服务器提示用户同意该请求。如果 用户发现请求有问题并拒绝请求，授权 服务器仍然 会将用户代理重定向到网络钓鱼网站。在这种情况下，无论用户 执行什么操作，用户代理 都会被重定向到网络钓鱼网站。¶

3. 故意发送有效的静默认证 请求（prompt=none）， 其中 client_id 和 redirect_uri 由 攻击者控制。在这种情况下， 授权服务器会自动将用户代理重定向到 网络钓鱼网站。¶

授权服务器必须采取预防措施防止这些 威胁。授权服务器必须始终 先认证用户，并且除静默认证 用例外，在重定向 用户之前，在需要时提示用户输入凭据。根据其风险评估，授权服务器需要决定是否 可以信任 重定向 URI。它可以考虑内部执行的 URI 分析 或通过某些外部服务进行的分析，以评估 URI 后内容的可信度和 可信性，以及重定向 URI 和 其他客户端数据的来源。¶

授权服务器应该仅在信任 重定向 URI 时自动重定向 用户代理。如果不信任该 URI，授权服务器可以告知用户， 并依赖 用户做出正确决定。¶

7.15.1. 通过发行者标识 防御混淆攻击

此防御方式要求客户端比较 授权服务器在授权响应中发送给客户端的发行者标识符值。收到授权 响应时，客户端必须将收到的发行者标识符与已存储的 发行者标识符进行比较。如果不匹配，客户端必须中止 交互。¶

可以通过不同方式将此发行者标识符传输 给客户端：¶

• 发行者信息通过响应 参数 iss 传输 （参见第 4.1.2 节）。¶

• 使用 OpenID Connect 且在授权 响应中返回 ID Token 时，客户端可以评估 ID Token 中的 iss 声明。¶

在这两种情况下，都必须按照 [RFC9207] 评估 iss 值。¶

虽然这种防御方式可能需要使用额外参数来 传输 发行者信息，但它是一种稳健且相对简单的混淆攻击防御方式。¶

7.15.2. 通过不同重定向 URI 防御混淆攻击

对于此防御方式，客户端必须为与其交互的每个 发行者 使用不同的重定向 URI。¶

客户端必须通过将发行者对应的不同重定向 URI 与 接收到授权响应的 URI 进行比较，检查授权响应是否 来自正确的 发行者。如果不匹配，客户端 必须中止流程。¶

虽然这种防御方式建立在现有 OAuth 功能之上，但 在客户端仅注册一次便用于多个不同 发行者的场景（例如某些开放银行方案）中无法使用，并且由于它与 客户端注册紧密集成，因此更难以自动部署。¶

此外，攻击者可能能够通过 使用客户端分配给攻击者 AS 的重定向 URI，在“诚实的”AS 上注册一个新客户端，从而绕过 此防御提供的保护。然后攻击者可以像上面所述那样运行 攻击，将 客户端 ID 替换为其新创建客户端的客户端 ID。¶

因此，只有在其他选项不可用时才应该使用此防御方式。¶

8.1.1. 原生应用客户端的注册

除非使用类似动态客户端注册 [RFC7591] 的机制来为 每个实例配置凭据，否则原生应用 被分类为公共客户端，如第 2.1 节所定义， 并且必须以此身份在授权服务器处注册。 授权服务器必须在客户端注册详细信息中记录客户端类型， 以便识别并相应地处理请求。¶

8.1.2. 原生应用 证明

草案规范 [I-D.ietf-oauth-attestation-based-client-auth] 定义了一种原生应用可用于获取 密钥绑定证明的机制，以向授权服务器或 资源服务器进行认证。这可以为 移动应用的身份提供更高程度的保证。¶

8.4.1. 声明的 "https" 方案 URI 重定向

某些操作系统，尤其是移动操作系统， 允许应用声明其控制域中的 https URI （参见 第 4.2.2 节（[RFC9110]））。 当浏览器遇到已声明的 URI 时，不是在浏览器中加载页面，而是 启动原生应用，并将该 URI 作为启动参数提供给它。¶

原生应用可以使用此类 URI 作为重定向 URI。对于授权服务器而言，它们 与常规基于 Web 的客户端重定向 URI 无法区分。例如：¶

https://app.example.com/oauth2redirect/example-provider

由于仅凭重定向 URI 不足以区分公共原生 应用客户端和机密 Web 客户端，因此第 8.1.1 节要求在客户端 注册期间记录客户端类型，以使服务器能够确定客户端类型并 相应处理。¶

与其他原生应用重定向选项相比，应用声明的 https 方案重定向 URI 具有一些优势， 因为目标应用的身份 由操作系统向授权服务器保证。因此，在可能的情况下，原生应用应该优先使用它们，而不是 其他选项。¶

8.4.2. 环回 接口重定向

能够在无需特殊权限的情况下打开环回网络 接口端口的原生应用（通常是 桌面操作系统上的应用）可以使用环回接口来接收 OAuth 重定向。¶

环回重定向 URI 使用 http 方案，并 使用 环回 IP 字面量以及客户端正在监听的任意端口构造。¶

也就是说，IPv4 使用 http://127.0.0.1:{port}/{path}， IPv6 使用 http://[::1]:{port}/{path}。下面是一个使用 IPv4 环回接口和随机分配端口的重定向示例：¶

http://127.0.0.1:51004/oauth2redirect/example-provider

下面是一个使用 IPv6 环回接口和 随机 分配端口的重定向示例：¶

http://[::1]:61023/oauth2redirect/example-provider

虽然使用名称 localhost 的重定向 URI（即 http://localhost:{port}/{path}）与环回 IP 重定向的工作方式类似，但不建议使用 localhost。 指定使用环回 IP 字面量的 重定向 URI，而不是 localhost，可以避免无意中监听 环回接口之外的网络接口。它也更不容易 受到客户端防火墙以及用户设备上主机名 解析配置错误的影响。¶

对于环回 IP 重定向 URI，授权服务器必须允许在请求时指定任意端口， 以适应 在请求时从操作 系统获取可用临时端口的客户端。¶

客户端不应该假定设备支持某个特定版本的 Internet Protocol。建议客户端 尝试使用 IPv4 和 IPv6 绑定环回接口， 并使用其中可用的一个。¶

8.4.3. 私有使用 URI 方案重定向

许多移动和桌面计算平台支持通过 URI 进行应用间 通信，方式是允许应用注册私有使用 URI 方案（有时通俗地称为“自定义 URL 方案”），例如 com.example.app。当浏览器或其他应用尝试 加载使用私有使用 URI 方案的 URI 时，会启动注册该方案的应用 来处理请求。¶

许多支持私有使用 URI 方案的环境并不 提供 声明某个方案并阻止其他方使用 另一个应用方案的机制。因此，使用私有使用 URI 方案的客户端容易受到针对其重定向 URI 的潜在攻击， 所以只有在前面提到的更安全 选项不可用时才应该使用此选项。¶

要使用私有使用 URI 方案重定向执行授权请求，原生应用会使用标准 授权请求启动浏览器，但其重定向 URI 使用 已在操作系统中注册的私有使用 URI 方案。¶

选择与应用关联的 URI 方案时，应用必须使用 基于其控制的域名的 URI 方案，并以 反向顺序表示，如 第 3.8 节（[RFC7595]）针对 私有使用 URI 方案所建议。¶

例如，控制域名 app.example.com 的应用可以使用 com.example.app 作为其方案。某些授权 服务器根据域名分配客户端标识符，例如 client1234.usercontent.example.net，在以相同方式反转后，也可以将其用作 方案的域名。然而，像 myapp 这样的 方案不满足此要求，因为 它并非基于域名。¶

当同一发布者拥有多个应用时，必须注意 确保该组中的每个方案都是唯一的。在使用 基于反向域名的应用标识符的平台上，这些 标识符可以重新用作 OAuth 重定向的私有使用 URI 方案，以帮助避免此问题。¶

按照 第 3.2 节（[RFC3986]）的要求，由于 私有使用 URI 方案重定向不存在 命名机构，因此方案组成部分之后只出现 一个斜杠（/）。使用私有使用 URI 方案的完整 重定向 URI 示例如下：¶

com.example.app:/oauth2redirect/example-provider

当授权服务器完成请求时，它会像往常一样重定向到 客户端的重定向 URI。由于 重定向 URI 使用私有使用 URI 方案，因此 操作系统会启动原生应用，并将该 URI 作为 启动参数传入。然后，原生应用使用常规流程处理 授权响应。¶

8.5.1. 原生应用中的嵌入式用户 代理

嵌入式用户代理在技术上可以用于授权原生 应用。根据定义，这些嵌入式用户代理对于授权服务器的第三方而言并不安全， 因为托管 嵌入式用户代理的应用可以访问用户完整的认证 凭据，而不仅仅是原本授予 该应用的 OAuth 授权许可。它们通常还会受到操作系统 的沙箱限制，并且依赖 Web 来源的 WebAuthn 等机制会被禁用。¶

在典型的基于 WebView 的嵌入式用户代理实现中， 宿主应用程序可以记录登录 表单中输入的每次按键以捕获用户名和密码，自动提交表单 以绕过用户同意，并复制会话 Cookie，使用它们 以用户身份执行经过认证的操作。¶

即使由与 授权服务器属于同一方的受信任应用使用，嵌入式用户代理也违反最小 权限原则，因为它们可以访问比 实际所需更强大的凭据，从而可能扩大攻击面。¶

鼓励用户在没有浏览器通常具有的地址栏和可见证书验证 功能的嵌入式用户代理中输入凭据， 会使用户无法知道 自己是否正在登录合法网站；即使确实如此，这也会 训练用户认为无需先验证网站便输入凭据是可以接受的。¶

除了安全问题之外，嵌入式用户代理不会与其他应用或浏览器共享 认证状态，因此 用户必须为每个授权请求登录，这通常 被认为是较差的用户体验。¶

8.5.2. 原生应用中的伪造外部 用户代理

发起授权请求的原生应用对 用户界面具有很大程度的控制权，并可能 呈现伪造的外部用户代理，即 被伪装成外部用户代理的嵌入式用户代理。¶

当所有良性参与方都使用外部用户代理时，其优势 在于安全专家能够检测恶意参与方，因为 任何伪造外部用户代理的行为都可以被证明是恶意的。另一方面， 如果良性和恶意参与方都使用嵌入式用户代理， 恶意参与方无需伪造任何东西，因此更难被发现。 一旦检测到恶意应用，就可能利用这些 信息在恶意软件扫描 软件中将应用签名列入黑名单、执行移除操作（对于由应用 商店分发的应用）以及采取其他措施来减少 恶意应用的影响和传播。¶

授权服务器还可以通过要求一种仅真正的外部 用户代理可用的认证因素，直接防御伪造的外部 用户代理。¶

在使用应用内浏览器标签页时特别关注自身安全的用户， 还可以采取额外步骤，从应用内浏览器标签页中 在完整浏览器里打开请求，并在那里完成 授权，因为大多数应用内 浏览器标签页模式的实现都提供此功能。¶

8.5.3. 原生应用中的恶意 外部用户代理

如果恶意应用能够将自己配置为操作系统中 https 方案 URI 的默认处理程序， 它就能够 拦截使用默认浏览器的授权请求，并 滥用这一受信任位置实施网络钓鱼等恶意行为。¶

这种攻击并不限于 OAuth；以 此方式配置的恶意应用会给用户带来一种超出 原生应用 OAuth 使用范围的普遍且持续的风险。许多操作系统通过 要求用户执行明确操作才能更改 http 和 https 方案 URI 的默认处理程序来缓解此 问题。¶

8.5.4. 原生应用中的环回 重定向注意事项

环回接口重定向 URI 可以使用 http 方案（即不使用 TLS）。对于环回 接口重定向 URI，这是可以接受的，因为 HTTP 请求永远不会离开设备。¶

客户端应该仅在开始 授权请求时打开网络端口，并在响应返回后关闭它。¶

客户端应该仅监听环回网络接口，以 避免其他网络参与方的干扰。¶

客户端应该使用环回 IP 字面量，而不是字符串 localhost， 如第 8.4.2 节所述。¶