2.1. 请求对象

请求对象是一个 JSON Web Token (JWT) [RFC7519]，其 JWT 声明 集包含经过 JSON 编码的 OAuth 2.0 授权请求 参数。¶

2.2. 请求对象 URI

请求对象 URI 是一个绝对 URI，它引用构成 OAuth 2.0 授权请求的一组参数。该 URI 所引用 资源的内容是一个 请求 对象（第 2.1 节），除非该 URI 是由同一授权服务器提供给客户端的，在这种情况下， 其内容属于由 授权服务器自行决定的实现细节。要求内容为请求对象，是为了确保在 request_uri 的提供者与消费者是不同 实体的情况下实现互操作性，例如客户端提供一个 URI， 该 URI 引用存储在客户端后端服务上的请求对象， 并通过 HTTPS 使其可访问。在后一种情况下，即 授权服务器既是该 URI 的提供者又是消费者，例如 它提供一个端点，用请求对象换取一个 URI 时，则不存在这种互操作性问题。¶

5.1. 按值传递请求 对象

客户端将授权请求作为 请求对象，以 request 参数值的形式发送到授权端点。¶

以下是一个使用 request 参数的授权 请求示例 （值中的换行仅用于显示）：¶

  https://server.example.com/authorize?client_id=s6BhdRkqt3&
    request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
    ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
    ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
    ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
    ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
    b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
    OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
    ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
    0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
    uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
    YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
    9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
    j1i7tLR_5Nz-g

5.2. 按引用传递请求 对象

request_uri 授权请求参数使 OAuth 授权请求能够按引用而不是 按值传递。此参数的使用方式与 request 参数相同，区别在于请求对象值是 从指定 URI 所标识的资源中检索， 而不是按值传递。¶

整个请求 URI 不应该超过 512 个 ASCII 字符。 此限制有两个原因：¶

1. 在撰写本文时，市场上的许多手机仍不接受 较大的载荷。限制通常为 512 或 1024 个 ASCII 字符。¶
2. 在 2G 移动连接等慢速连接上，较大的 URL 会导致响应缓慢；因此，从用户体验角度来看， 不建议使用这样的 URL。¶

request_uri 所引用资源的内容 必须是请求对象，并且必须 可由授权服务器访问， 除非该 URI 是由授权服务器提供给客户端的。 在第一种情况下，request_uri 必须是 https URI， 如 第 2.7.2 节（[RFC7230]）中所规定。 在第二种情况下，它必须是 URN， 如 [RFC8141] 中所规定。¶

以下是一个 可由 request_uri 引用的 请求对象资源内容示例 （值中的换行仅用于显示）：¶

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

  https://tfp.example.org/request.jwt/
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

  https://server.example.com/authorize?
    client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org

  HTTP/1.1 200 OK
  Date: Thu, 20 Aug 2020 23:52:39 GMT
  Server: Apache/2.4.43 (tfp.example.org)
  Content-type: application/oauth-authz-req+jwt
  Content-Length: 797
  Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

6.1. JWE 加密的请求 对象

如果请求对象已加密， 授权服务器必须按照 JSON Web 加密 [RFC7516] 规范解密 JWT。¶

结果是一个已签名的请求对象。¶

如果解密失败，授权服务器必须 在对授权请求的响应中向客户端 返回 invalid_request_object 错误。¶

6.2. JWS 签名的请求 对象

授权服务器必须验证 经 JWS 签名的 [RFC7515] 请求 对象的签名。如果存在 kid 头部参数，则所标识的密钥 必须是使用的密钥，并且必须是 与客户端关联的密钥。签名必须 使用与客户端关联的密钥以及 alg 头部参数中指定的算法进行验证。必须执行算法验证，如 [RFC8725] 的第 3.1 节和第 3.2 节中所规定。¶

如果密钥未与客户端关联，或者签名 验证失败，授权服务器必须 在对授权请求的响应中向客户端返回 invalid_request_object 错误。¶

6.3. 请求参数 组装和验证

授权服务器必须从 请求对象值中提取 授权请求参数集合。 即使查询参数中提供了 相同参数，授权服务器也必须仅使用 请求对象中的参数。 client_id 请求参数中的客户端 ID 值 与请求对象 client_id 声明中的值必须 完全相同。 然后，授权服务器按照 OAuth 2.0 [RFC6749] 中的规定验证请求。¶

如果客户端 ID 检查或请求验证失败，则 授权服务器必须在对授权请求的响应中向 客户端返回错误，如 第 5.2 节（[RFC6749]）（OAuth 2.0）中所规定。¶

9.1. OAuth 参数 注册

由于请求对象是 JWT，因此核心 JWT 声明不能 在请求对象中用于 JWT 所规定用途之外的任何用途。 因此，它们已被注册为 OAuth 授权请求参数，以避免未来的 OAuth 扩展 使用这些参数表达不同含义。¶

本规范向由 [RFC6749] 建立的“OAuth 参数”注册表 [IANA.OAuth.Parameters] 添加以下值。¶

名称：

iss¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.1 节（[RFC7519]）。¶

名称：

sub¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.2 节（[RFC7519]）。¶

名称：

aud¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.3 节（[RFC7519]）。¶

名称：

exp¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.4 节（[RFC7519]）。¶

名称：

nbf¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.5 节（[RFC7519]）。¶

名称：

iat¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.6 节（[RFC7519]）。¶

名称：

jti¶

参数使用位置：

授权请求¶

变更控制者：

IETF¶

规范文档：

本文档以及 第 4.1.7 节（[RFC7519]）。¶

9.2. OAuth 授权 服务器元数据注册表

本规范向由 [RFC8414] 建立的“OAuth 授权服务器元数据”注册表 [IANA.OAuth.Parameters] 添加以下值。¶

元数据名称：

require_signed_request_object¶

元数据描述：

指示授权 请求是否需要作为请求对象受到保护，并通过 request 或 request_uri parameter 提供。¶

变更控制者：

IETF¶

规范文档：

本文档的第 10.5 节。¶

9.3. OAuth 动态客户端 注册元数据注册表

本规范向由 [RFC7591] 建立的“OAuth 动态 客户端注册元数据”注册表 [IANA.OAuth.Parameters] 添加以下值。¶

元数据名称：

require_signed_request_object¶

元数据描述：

指示授权 请求是否需要作为请求对象受到保护，并通过 request 或 request_uri parameter 提供。¶

变更控制者：

IETF¶

规范文档：

本文档的第 10.5 节。¶

9.4. 媒体类型 注册

10.1. 算法选择

通过 request 参数发送授权请求对象时，它必须 使用 JWS [RFC7515] 进行签名， 或者分别使用 JWS [RFC7515] 和 JWE [RFC7516] 先签名再加密， 并采用当时被认为适当的算法。¶

10.2. 请求来源 身份验证

授权请求的来源必须始终 进行验证。有以下几种方法：¶

(a)

验证请求对象的 JWS 签名。¶

(b)

如果 JWE 使用对称加密，则验证用于 JWE 加密的对称密钥是否 正确。但请注意， 如果使用公钥加密，则加密本身无法实现来源身份验证，因为任何一方都可以使用该公 钥进行加密。¶

(c)

验证请求对象 URI 的 TLS 服务器身份。 在这种情况下，授权服务器必须通过 带外方式获知客户端使用请求对象 URI，并且 TLS 证书仅涵盖该客户端。 通常，这并不是一种可靠的方法。¶

(d)

当授权服务器实现一种 以请求对象换取请求对象 URI 的 服务时，授权 服务器必须执行客户端身份验证以接受 请求对象，并将客户端标识符 绑定到其提供的请求对象 URI。 它必须按照 (a) 验证签名。 由于请求对象 URI 可以被重放，因此请求对象 URI 的有效期 必须很短，并且最好 只能使用一次。请求对象 URI 的熵 必须足够大。 适当短的有效期以及 请求对象 URI 的熵取决于 基于受保护资源价值所进行的 风险计算。关于有效期的一般指导 是应少于一分钟， 并且在撰写本规范时，请求对象 URI 应包含 128 位或更多位的加密 随机值。¶

(e)

当受信任的第三方服务以请求对象换取请求对象 URI 时，它必须按照 (a) 验证 签名。此外，授权服务器 必须受该第三方服务信任，并且 必须通过带外方式获知客户端也受其信任。¶

10.3. 显式端点

尽管本规范并不要求这样做， 但 [BASIN] 等研究指出， 以防篡改的方式明确说明 预期的交互端点以及消息在序列中的 位置是一种良好实践， 从而使发起者的意图明确无歧义。本规范 建议对 [RFC6749]、[RFC6750] 和 [RFC8414] 中定义的以下端点采用这种 做法：¶

(a)

受保护资源（protected_resources）¶

(b)

授权端点（authorization_endpoint）¶

(c)

重定向 URI（redirect_uri）¶

(d)

令牌端点（token_endpoint）¶

此外，如果使用动态发现，那么这种做法也适用于 与发现相关的端点。¶

在 [RFC6749] 中， 重定向 URI 包含在授权请求中，而其他端点 则不包含。因此，授权 请求对象也同样如此。¶

10.4. 与 request_uri 相关的风险

引入 request_uri 会带来多种可能的攻击。 有关与 URI 相关的风险的更多信息， 请参阅 第 7 节（ [RFC3986]）中的安全注意事项。¶

10.5. 降级攻击

除非客户端和服务器所使用的协议被限定为 使用 OAuth JWT 保护的授权请求 (JAR)，否则攻击者可能 使用 RFC 6749 请求 绕过本规范提供的所有保护。¶

为防止这种攻击，本规范定义了新的 客户端元数据值和服务器元数据值，两者均名为 require_signed_request_object，其值均为 布尔值。¶

当其作为客户端元数据的值为 true 时， 服务器必须拒绝来自 不符合本规范的客户端的授权请求。当此服务器 元数据值为 true 时，如果请求对象 使用的 alg 值为 none，它也 必须拒绝该请求。如果省略，默认值为 false。¶

当其作为服务器元数据的值为 true 时， 服务器必须拒绝来自 任何不符合本规范的客户端的授权请求。如果请求对象 使用的 alg 值为 none，它也 必须拒绝该请求。如果省略， 默认值为 false。¶

请注意，即使不存在 require_signed_request_object 元数据 值，只要客户端和服务器共同支持某些签名算法， 客户端可以使用已签名的请求对象。 签名算法元数据的使用在 第 4 节中说明。¶

10.6. TLS 安全 注意事项

当前的安全 注意事项可参见“安全使用 传输层安全性 (TLS) 和数据报传输层安全性 (DTLS) 的建议” [RFC7525]。这 取代了 OAuth 2.0 [RFC6749] 中的 TLS 版本建议。¶

10.7. 参数不匹配

鉴于 OAuth 参数值会在两个不同的位置发送， 即作为普通 OAuth 参数和作为请求对象声明， 实现必须防范可能利用不匹配的 参数值获得非预期结果的攻击。 这就是两个客户端 ID 值必须匹配的原因， 也是只能使用请求对象中的参数值的原因， 同样也是 request 和 request_uri 均不能出现在请求对象中的原因。¶

10.8. 跨 JWT 混淆

如 第 2.8 节（[RFC8725]）中所述， 攻击者可能试图将在某一用途下签发的 JWT 用于其原本并不适用的上下文中。 针对此类攻击所述的缓解措施可以应用于请求对象。¶

攻击者可能试图重新利用请求对象的一种方式 是尝试将其用作客户端身份验证 JWT， 如 第 2.2 节（[RFC7523]）中所述。 防止这种情况的一种简单方法是绝不在请求对象中将客户端 ID 用作 sub 值。¶

防止跨 JWT 混淆的另一种方式是使用显式类型， 如 第 3.11 节（[RFC8725]）中所述。 可以通过包含值为 oauth-authz-req+jwt 的 typ 头部参数来显式指定请求对象的类型 （该值已在 第 9.4.1 节中注册）。 但请注意，要求现有授权服务器使用显式指定类型的请求对象 会破坏大多数现有部署， 因为现有客户端已经普遍使用未指定类型的请求对象， 尤其是在 OpenID Connect [OpenID.Core] 中。 不过，对于无需考虑与现有部署兼容性的 新 OAuth 部署配置文件而言， 要求显式指定类型会是一个好主意。¶

最后，防止跨 JWT 混淆的另一种方式是采用一种密钥 管理机制，使得用于签署请求对象的密钥 能够明确区分于用于其他用途的密钥。这样，如果 攻击者试图在其他上下文中重新利用请求对象，就会发生密钥 不匹配，从而阻止攻击。¶

11.1. 收集限制

当客户端被授予访问包含个人数据的受保护资源的权限时， 客户端应该将 个人数据的收集限制在适用法律允许的范围内， 并且仅限于指定目的严格必需的数据。¶

用户通常很难确定所请求的个人数据 是否严格必要。受信任的第三方服务可以通过 检查客户端请求，将其与客户端拟进行的 处理相比较，并对该请求进行认证来帮助用户。认证 完成后，客户端在发出授权请求时，可以 向受信任的第三方服务提交授权请求，以 获取请求对象 URI。此过程分为两个步骤：¶

(1)

（认证过程）受信任的第三方服务检查 客户端的业务流程，并确定其 需要哪些声明；这就是认证过程。客户端通过 认证后，会获得客户端凭据，用于进行身份验证， 以便将请求对象推送到受信任的第三方服务 来获取 request_uri。¶

(2)

（转换过程）客户端使用其获得的客户端凭据， 将请求对象推送到受信任的第三方服务， 以获取 request_uri。受信任的第三方服务 还会按照前一步骤验证请求对象是否与 客户端有资格请求的声明一致。¶

在授权请求中收到这样的请求对象 URI 后， 授权服务器首先验证 请求对象 URI 的 authority 部分对于受信任的第三方 服务是否合法。然后，授权服务器向 请求对象 URI 发出 HTTP GET 请求。连接建立后，授权服务器 必须验证 TLS 证书中表示的服务器身份 对于该请求对象 URI 是否合法。然后， 授权服务器可以获取请求对象，其中包含 表示客户端的 client_id。¶

同意界面必须指明客户端，并且 应该指明该请求已经过 受信任第三方服务的审查，以确认其遵守收集 限制原则。¶

11.2. 披露限制