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

Question

OpenID Connect Basic Client Implementer's Guide claims in section 2.1.6.1 客户端必须向身份提供者的 /token 路由发送 POST 请求才能交换令牌的授权代码。

那里显示的示例如下所示：

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 部分最初请求授权码的 copy/paste 错误，还是我遗漏了什么？

Answer 1

No I wonder, if the response is not given using a redirect, but is directly sent to the client, then why does the request above contain a redirect_uri parameter?

将 redirect_uri 发送到令牌端点实际上是一项安全功能，在 OAuth 2.0 Authorization Framework specification:

中有很好的解释

When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code.

An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker's user-agent is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client.

Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and trusted client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account, which can now gain access to the protected resources authorized by the victim (via the client).

In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token. The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value.

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

The authorization server should be able to bind every authorization "code" to the actual redirect URI used as the redirect target of the client in the end-user authorization process. This binding should be validated when the client attempts to exchange the respective authorization "code" for an access token. This measure is a countermeasure against authorization "code" leakage through counterfeit web sites, since an attacker cannot use another redirect URI to exchange an authorization "code" into a token.

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

Exchanging a code for a token in OpenID Connect authorization code flow

authorization

oauth-2.0

openid-connect