Question

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

Answer 1

防止攻击者操纵身份验证请求并使授权服务器将代码发送到攻击者控制下的URL。

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

推理是此处规范的安全注意事项的一部分：https://tools.ietf.org/html/rfc6749#section-10.6

使用授权代码授予请求授权时   类型，客户端可以通过“redirect_uri”指定重定向URI   参数。如果攻击者可以操纵
的值   重定向URI，它可以导致授权服务器重定向
  资源所有者user-agent到一个受控制的URI   攻击者使用授权码。

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

客户端的重定向URI，其URI在控制下   攻击者。然后攻击者欺骗受害者进入   操纵链接以授权访问合法客户端。

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

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

Answer 2

Hans Z.的答案在我阅读规范时似乎是正确的。 https://tools.ietf.org/html/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的auth基础设施访问资源所有者。

我的假设：

（D）是安全的（通过某种方式，可能是client_secret和TLS。确切的机制在RFC中未定义）
客户端不是公司1专门列入白名单的资源。这是RFC推荐，但不是必需的。

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

公司3将自身（BadClient）作为中间人插入User-Agent和Client Company 2客户端。
假重定向URI指向BadClient Company 3并显示虚假页面。这些页面欺骗用户通过公司1对公司2进行身份验证（client_id为Client2），并且公司3由于伪重定向（C）而成功接收到身份验证代码。用户认为Company3创建的虚假页面实际上属于Company2。
恶意客户端制作（C）＆＃39; BadClient向客户提出请求，因为它已代表用户收到授权代码。例如，www.company2client.com？code = \＆amp; state = \，试图获取只有公司2应该有权访问的accessToken。客户公司2将请求及其client_secret（只有公司2知道这一点）及其redirect_url（问题是为什么？）转发给Auth服务器，然后将访问令牌返回给（E），然后将其传递回恶意客户中间人。 GAME OVER。
要停止此攻击，授权服务器可以比较（A）和（D）之间的重定向URL。授权请求（BadClient）的redirect_url与access_token请求（客户端）中提供的redirect_url不匹配。请注意，拥有redirect_urls的注册白名单可以在授权请求（A）中解决此问题，但这只是RFC的推荐，而不是必须具有的。相反，RFC声明在（D）中提供redirect_url是必须的，而不是强制要求白名单。

Answer 3

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

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

3 个答案: