OAuth 2.1 授权框架

1.3.1. 授权码

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

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

授权码提供了一些重要的安全优势， 例如认证客户端的能力，以及将访问令牌直接传输给客户端， 而无需让它经过资源所有者的用户代理并可能暴露给其他方， 包括资源所有者。¶

1.3.2. 刷新令牌

刷新令牌是用于获得访问令牌的凭据。刷新令牌可以由 授权服务器颁发给客户端，并用于在当前访问令牌变为无效或过期时 获得新的访问令牌，或者用于获得具有相同或更窄范围的 其他访问令牌（访问令牌可以比资源所有者授权的生命周期更短、 权限更少）。是否颁发刷新令牌由授权服务器自行决定， 并且可以基于客户端属性、请求属性、授权服务器内的策略或 任何其他条件来颁发。如果授权服务器颁发刷新令牌， 则在颁发访问令牌时包含它（即 图 2 中的步骤 (2)）。 刷新令牌的生命周期也由授权服务器自行决定。¶

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

+--------+                                           +---------------+
|        |--(1)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(2)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(3)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(4)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(5)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(6)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(7)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(8)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

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

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

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

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

4. 资源服务器验证访问令牌； 如果有效，则为该请求提供服务。¶

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

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

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

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

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

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

1.3.3. 客户端凭据

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

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 Profile for Access Tokens [RFC9068] 中描述了访问令牌的一种 编码和签名机制示例。¶

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

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

授权服务器和资源服务器应使用用于发送方约束访问令牌的机制， 例如 OAuth Demonstration of Proof of Possession (DPoP) [RFC9449] 或 Mutual TLS for OAuth 2.0 [RFC8705]。 请参见 [RFC9700] 的 第 4.10.1 节，以防止被窃取和泄露的 访问令牌被滥用。¶

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

2.3.1. 注册 要求

授权服务器必须要求客户端注册其完整的重定向 URI （包括路径组件）。授权服务器必须拒绝指定了与已注册 URI 不完全匹配的重定向 URI 的授权请求；回环重定向除外， 其中除端口 URI 组件外仍要求精确匹配，详见 第 4.1.1 节。¶

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

注册可以带外发生，例如在授权服务器配置客户端信息的手动步骤； 也可以在运行时发生，例如在 Pushed Authorization Requests [RFC9126] 中的初始 POST。¶

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

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

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

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

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

2.3.2. 多个重定向 URI

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

2.3.3. 防止 CSRF 攻击

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

2.3.4. 防止 混淆攻击

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

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

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， 如 [RFC7591] 的 第 2 节 中所定义。¶

例如，使用内容参数刷新访问令牌 （第 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 认证方案， 用于认证已颁发客户端密钥的客户端。¶

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

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

例如（额外换行仅用于显示目的）：¶

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

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

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

2.4.2. 其他 认证方法

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

一些额外认证方法，例如 mTLS [RFC8705] 和 Private Key JWT（[RFC7523]、 [I-D.ietf-oauth-rfc7523bis]） 定义在 “OAuth Token Endpoint Authentication Methods” 注册表中， 并且作为通用客户端认证方法可能很有用，而不仅限于保护令牌端点的特定用途。¶

3.2.1. 客户端 认证

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

客户端认证用于：¶

• 强制刷新令牌和授权码与其被颁发给的客户端绑定。 当授权码通过不安全通道传输到重定向端点时， 客户端认证会添加一层额外安全性。¶

• 通过禁用客户端或更改其凭据， 从客户端被攻破中恢复，从而防止攻击者滥用被窃取的刷新令牌。 更改单组客户端凭据明显快于撤销整组刷新令牌。¶

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

3.2.2. 令牌端点 请求

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

"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 响应标头字段 （参见 [RFC9111] 的 第 5.2 节），其值为 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"
}

客户端必须忽略响应中未识别的值名称。 从授权服务器接收的令牌和其他值的大小保持未定义。 客户端应避免对值大小作出假设。授权服务器应记录其颁发的任何值的大小。¶

3.2.4. 令牌端点 错误响应

授权服务器以 HTTP 400 (Bad Request) 状态码响应 （除非另有指定），并在响应中包含以下参数：¶

"error"：

必需。来自以下内容的单个 ASCII [USASCII] 错误代码：¶

"invalid_request"：

请求缺少必需参数， 包含不受支持的参数值（授予类型除外）， 重复参数，包含多个凭据，使用超过一种机制认证客户端， 在授权请求中未发送 code_challenge 的情况下包含 code_verifier，或在其他方面格式错误。¶

"invalid_client"：

客户端认证失败（例如未知客户端、 未包含客户端认证，或不受支持的认证方法）。 授权服务器可以返回 HTTP 401 (Unauthorized) 状态码， 以指示支持哪些 HTTP 认证方案。如果客户端尝试通过 Authorization 请求标头字段进行认证， 授权服务器必须以 HTTP 401 (Unauthorized) 状态码响应， 并包含与客户端所用认证方案匹配的 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 之外的字符。¶

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

例如：¶

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"：

可选，如果请求中不存在则默认为 plain。 代码验证器转换方法为 S256 或 plain。¶

"redirect_uri"：

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

"scope"：

可选。如 第 1.4.1 节 所述的访问请求范围。¶

"state"：

可选。客户端用于在请求和回调之间 维护状态的不透明值。授权服务器在将用户代理 重定向回客户端时包含此值。¶

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)))

plain
  code_challenge = code_verifier

如果客户端能够使用 S256，则它必须使用 S256，因为 S256 是服务器必须实现（MTI）的。仅当客户端因某些 技术原因无法支持 S256，例如没有可用哈希函数的受限环境， 并且通过带外配置或通过 Authorization Server Metadata [RFC8414] 知道服务器支持 plain 时，才允许客户端使用 plain。¶

code_challenge 的 ABNF 如下。¶

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

属性 code_challenge 和 code_verifier 采用自 OAuth 2.0 扩展 “Proof-Key for Code Exchange”，即 PKCE [RFC7636]，该技术最初在其中开发。¶

授权服务器必须支持 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 相等；有关详细信息，请参见 [RFC3986] 的 第 6.2.1 节，简单字符串比较。 唯一例外是使用 localhost URI 的原生应用：在这种情况下， 授权服务器必须允许可变端口号，如 [RFC8252] 的 第 7.3 节 所述。¶

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

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

4.1.2. 授权 响应

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

"code"：

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

"state"：

如果客户端 授权请求中存在 state 参数，则必需。 从客户端接收到的确切值。¶

"iss"：

可选。授权服务器的标识符； 如果客户端与多个授权服务器交互， 客户端可使用它来防止混淆攻击。有关此参数何时必要， 以及客户端如何使用它来防止混淆攻击的更多详细信息， 请参见 第 7.14 节 和 [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

客户端必须忽略未识别的响应参数。 授权码字符串大小由本规范保持未定义。 客户端应避免对 code 值大小作出假设。 授权服务器应记录其颁发的任何值的大小。¶

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

服务器用于将 code_challenge 与已颁发 code 相关联的确切方法超出本规范范围。 代码挑战可以存储在服务器上，并在那里与 code 相关联。code_challenge 和 code_challenge_method 值可以 以加密形式存储在 code 本身中，但服务器 不得在响应参数中以 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.2 节。¶

例如，客户端发出以下 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 节 中的处理规则外， 授权服务器还必须：¶

• 确保授权码颁发给了已认证的 机密客户端，或者如果客户端是公开客户端， 则确保 code 颁发给了请求中的 client_id，¶

• 验证授权码有效，¶

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

• 如果存在 code_verifier， 则通过从接收到的 code_verifier 计算代码挑战， 并在先按照客户端指定的 code_challenge_method 方法 对其进行转换后，将其与先前关联的 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 标头字段语法 遵循 [RFC2617] 的 第 2 节 中定义的 Basic 方案用法。 请注意，与 Basic 一样，它不符合 [RFC2617] 的 第 1.2 节 中定义的通用语法， 但它与 HTTP 1.1 Authentication [RFC7235] 中的通用认证框架兼容， 尽管为了反映现有部署，它未遵循其中概述的首选 实践。Bearer 凭据的语法如下：¶

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

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

如 [RFC9110] 的 第 11.1 节 所述， 字符串 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 方法。¶

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

例如，客户端使用传输层安全发出以下 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 值旨在供程序使用，并不意味着显示给最终用户。¶

下面给出两个示例 scope 值；它们分别取自 OpenID Connect [OpenID.Messages] 和 Open Authentication Technology Committee (OATC) Online Multimedia Authorization Protocol [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 中指定） 不得包含用于表示 scope 值的集合 %x21 / %x23-5B / %x5D-7E 之外的字符，以及 scope 值之间分隔符使用的 %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 (Bad Request) 状态码响应。¶

"invalid_token"：

提供的访问令牌已过期、已撤销、 格式错误，或因其他原因无效。资源服务器应以 HTTP 401 (Unauthorized) 状态码响应。客户端可以 请求新的访问令牌并重试受保护资源 请求。¶

"insufficient_scope"：

该请求需要比授予客户端并由访问令牌表示的 范围所提供的权限（范围）更高的权限。 资源服务器应以 HTTP 403 (Forbidden) 状态码响应，并可以包含 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="The access token expired"

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

[RFC6750] 在 [RFC6749] 的 第 11.4 节 中建立了一个通用注册表，供 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 Special Publication 800-63 [NIST800-63]。¶

7.1.2. 威胁缓解

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

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

本文档不指定访问令牌的编码或内容； 因此，有关保证访问令牌完整性保护手段的详细建议 超出本规范范围。 JSON Web Token Profile for Access Tokens [RFC9068] 中描述了 访问令牌的一种编码和签名机制示例。¶

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

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

7.1.3. 建议 摘要

7.1.4. 访问令牌 权限限制

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

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

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

7.3.1. 冒充 原生应用

如上所述，授权 服务器不应在没有用户同意或交互的情况下自动处理授权请求， 除非能够确保客户端的身份。这包括用户先前已批准给定客户端 ID 授权请求的情况——除非能够证明客户端身份， 否则该请求应按没有先前请求被批准的方式处理。¶

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

7.3.2. 访问令牌 权限限制

客户端应请求具有必要最小范围的访问令牌。 授权服务器在选择如何满足所请求范围时应考虑客户端身份， 并可以颁发范围少于请求范围的访问令牌。¶

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

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

7.5.1. 授权 码注入

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

7.5.2. 授权码 重用

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

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

但是，只有当包含授权码的 请求本身也有效（包括任何其他参数，例如 code_verifier 和客户端认证）时，授权服务器才应撤销已颁发的令牌。 当收到包含无效参数的重放授权码时，授权服务器 不应撤销任何已颁发的令牌。如果这样做， 对于能够获得授权码但无法获得客户端认证或 code_verifier 的攻击者而言，就会创造拒绝服务机会： 攻击者可在合法客户端之前发送无效的授权码请求， 从而在合法客户端发出有效请求时撤销合法客户端的令牌。¶

7.5.3. HTTP 307 重定向

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

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

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

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

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

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

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

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

为了防止开放重定向，客户端应仅在 目标 URL 位于白名单中，或请求的来源和完整性可被认证时 才进行重定向。OWASP [owasp_redir] 描述了防范开放重定向的对策。¶

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

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

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

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

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

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

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

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

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

7.14.1. 通过颁发者标识进行 混淆防御

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

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

• 例如，颁发者信息可以通过可选响应参数 iss 传输（参见 第 4.1.2 节）。¶

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

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

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

7.14.2. 通过不同重定向 URI 进行 混淆防御

对于这种防御，客户端必须为其交互的每个 颁发者使用不同的重定向 URI。¶

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

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

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

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

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

除非使用类似 Dynamic Client Registration [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 字面量而非 localhost 的 重定向 URI，可以避免无意中监听回环接口之外的网络接口。 它也不太容易受到客户端防火墙和用户设备上配置错误的主机名解析的影响。¶

对于回环 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 等机制会被禁用。¶

在典型的基于 web-view 的嵌入式用户代理实现中， 宿主应用可以记录登录表单中输入的每一次按键， 以捕获用户名和密码，自动提交表单以绕过用户同意， 并复制会话 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 节 所述。¶