为什么 OAuth RFC 要求再次传递 redirect_uri 以交换令牌代码？答案

【问题标题】：Why does OAuth RFC require the redirect_uri to be passed again to exchange code for token?为什么 OAuth RFC 要求再次传递 redirect_uri 以交换令牌代码？
【发布时间】：2018-07-21 02:25:57
【问题描述】：

假设我的重定向 uri 和授权代码请求有效，并且我想用有效代码交换令牌，验证我在 access_code 请求中传递的重定向 URI 与授权代码中提供的相同 uri 匹配有什么好处请求？

【问题讨论】：

标签： oauth oauth-2.0

【解决方案1】：

防止攻击者操纵Authentication Request，使Authorization Server将代码发送到攻击者控制的URL。

如果只有一个向授权服务器注册的重定向 URI（最佳实践）但使用松散类型的匹配 - 例如接受特定域上的任何重定向 URI - 那么攻击者很可能会操纵该域的某些部分（例如，通过开放重定向、易受攻击的 wiki、论坛等）以获取 @ 987654322@ 并随后针对合法客户端重播。使用强制重定向 URI 后，授权服务器在授权请求中看到的重定向 URI 与客户端用于令牌端点的重定向 URI 之间将出现不匹配。如果根本没有预先注册重定向 URI，这种攻击就更加微不足道了。

推理是此处规范的安全考虑的一部分：https://www.rfc-editor.org/rfc/rfc6749#section-10.6

使用授权码授权请求授权时
类型，客户端可以通过“redirect_uri”指定一个重定向URI 范围。如果攻击者可以操纵
重定向URI，它可以导致授权服务器重定向
资源所有者用户代理到受

控制的 URI 具有授权码的攻击者。

攻击者可以在合法客户端创建一个帐户，然后启动授权流程。当攻击者的用户代理是发送到授权服务器以授予访问权限，攻击者获取合法客户端提供的授权 URI 和取代了

客户端的重定向URI与受控制的URI
攻击者。然后攻击者诱使受害者跟随
操纵链接以授权访问合法客户端。

一旦在授权服务器上，受害者会被提示一个
代表合法且受信任的客户的正常、有效请求，
并授权该请求。然后受害者被重定向到一个
具有授权的攻击者控制的端点
代码。攻击者通过发送
使用原始重定向 URI 向客户端发送授权码
由客户提供。客户端交换授权码
使用访问令牌并将其链接到攻击者的客户帐户，
现在可以访问由
授权的受保护资源受害者（通过客户端）。

为了防止这种攻击，授权服务器必须
确保用于获取授权码的重定向 URI 与交换时提供的重定向 URI 相同
访问令牌的授权码。授权服务器
必须要求公共客户并且应该要求机密客户
注册他们的重定向 URI。如果提供了重定向 URI 在请求中，授权服务器必须根据注册值。

【讨论】：

我仍然不清楚重新发送 URI 如何降低这种风险。劫持请求的任何人都知道这两个 URI，这不是真的吗？或者由于交换需要基本身份验证，并且服务器知道请求代码的客户端 ID，因此假设攻击者也需要拥有客户端密码是否安全？这将是一个完全不同的问题。
是合法客户端将重定向 URI 发送到令牌端点（因为攻击者对此使用 code）；合法客户端将发送合法的重定向 URI，该 URI 与攻击者使用的不匹配；这种攻击并不假设攻击者知道客户端的秘密，这确实是一种不同的攻击，无论如何都可能丢失东西

【解决方案2】：

从我对规范的阅读来看，Hans Z. 的答案似乎是正确的。 https://www.rfc-editor.org/rfc/rfc6749。我将尝试对相同内容进行其他解释。

首先，来自4.1节的验证码流程：

 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)' (C)'                                       |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

注意：说明步骤 (A)、(B) 和 (C) 的线条已断开当它们通过用户代理时分成两部分。

                 Figure 3: Authorization Code Flow

问题是为什么步骤 (D) 需要重定向 URI。

谁拥有什么：

授权服务器归公司 1 所有
客户端归公司 2 所有，使用公司 1 的身份验证基础架构访问资源所有者。

我的假设：

公司 1 和公司 2 之间的 (D) 是安全的（通过某种方式，可能是 client_secret 和 TLS。确切的机制在 RFC 中未定义）
客户不是公司 1 专门列入白名单的资源。这是 RFC 建议，但不是要求。

恶意客户公司 3 想要以公司 2 的名义访问资源所有者。

公司 3 将自己 (BadClient) 插入为用户代理和客户公司 2 客户端之间的中间人。
虚假重定向 URI 指向 BadClient 公司 3 并显示虚假页面。这些页面欺骗用户向公司 1 验证公司 2（client_id 是 Client2），公司 3 由于虚假重定向 (C) 成功接收到验证码。用户认为 Company3 创建的虚假页面实际上属于 Company2。
恶意客户端从 BadClient 向客户端发出 (C)' 请求，因为它代表用户收到了授权码。例如，www.company2client.com?code=\&state=<state>，试图获取只有公司 2 才能访问的 accessToken。 Client Company2 将请求连同它的 client_secret（只有 Company 2 知道这一点）和它的 redirect_url（问题是为什么？）一起转发到 Auth 服务器，然后将访问令牌返回给 (E)，然后将其传递回恶意客户端中间人。游戏结束。</state>
为了阻止这种攻击，授权服务器可以比较 (A) 和 (D) 之间的重定向 URL。授权请求（BadClient）的redirect_url 与access_token 请求（Client）中提供的redirect_url 不匹配。请注意，注册的 redirect_urls 白名单可以在授权请求 (A) 中解决此问题，但这只是 RFC 的建议，不是必须的。相反，RFC 声明在 (D) 中提供 redirect_url 是必须的，而不是强制要求白名单。

【讨论】：

【解决方案3】：

如 user892703 在最后一点中所述。如果授权步骤使用客户端在其注册阶段注册的白名单 uri 验证重定向 uri，则在令牌获取步骤中不需要重新发送 redirect_uri。

【讨论】：