Question

OpenID Connect Basic Client Implementer's Guide部分中的2.1.6.1声明客户必须向身份提供商的POST路由发送/token请求才能交换授权码为了一个令牌。

那里显示的样本如下所示：

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

我完全理解为什么需要提供grant_type参数，并且我也理解为什么需要提供code。

但我看一下2.1.6.2部分，使用重定向不会给出答案，而是使用JSON编码的正文发送一个简单的200响应：

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

{
  "access_token":"SlAV32hkKG",
  "token_type":"Bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
}

不，我不知道，如果使用重定向给出不的响应，但是直接发送到客户端，那么为什么上面的请求包含redirect_uri参数？

这是最初请求授权代码的2.1.2部分的复制/粘贴错误，还是我遗漏了某些内容？

Answer 1

不，我不知道，如果没有使用重定向给出响应，但是直接发送给客户端，那么为什么上面的请求包含redirect_uri参数？

将redirect_uri发送到令牌端点实际上是一项安全功能，在OAuth 2.0 Authorization Framework specification中有详细说明：

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

攻击者可以在合法客户端创建帐户并启动授权流程。当攻击者的用户代理被发送到授权服务器以授予访问权限时，攻击者会获取合法客户端提供的授权URI，并使用受攻击者控制的URI替换客户端的重定向URI。然后，攻击者欺骗受害者跟随操纵的链接以授权访问合法客户端。

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

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

OAuth 2.0 Threat Model and Security Considerations RFC中也提到了它：

授权服务器应该能够将每个授权“代码”绑定到在最终用户授权过程中用作客户端重定向目标的实际重定向URI。当客户端尝试为访问令牌交换相应的授权“代码”时，应验证此绑定。此措施是针对授权“代码”通过假冒网站泄漏的对策，因为攻击者无法使用其他重定向URI将授权“代码”交换为令牌。

在OpenID Connect交换授权代码流中交换令牌代码

1 个答案: