为什么 OAuth RFC 要求再次传递 redirect_uri 以交换令牌代码? [英] Why does OAuth RFC require the redirect_uri to be passed again to exchange code for token?

问题描述

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

Assuming my redirect uri and authorization code request was valid, and I want to exchange the valid code for a token, what is the benefit of validating that the redirect URI I pass in access_code requests matches the same uri provided in the authorization code request?

推荐答案

是为了防止攻击者操纵 Authentication Request 并使 Authorization Server 将代码发送到攻击者控制下的 URL.

It is to prevent an attacker from manipulating the Authentication Request and make the Authorization Server send the code to a URL under the attacker's control.

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

This attack is not be possible if there's only a single redirect URI that is registered with the Authorization Server (best practice) but when using a loose type of matching - e.g. any redirect URI on a specific domain is accepted - then it may very well be possible that some parts of that domain can be manipulated by the attacker (e.g. through open redirects, vulnerable wiki's, forums. etc.) to get a hold of the code and subsequently replay it against the legitimate client. With the mandatory redirect URI in place, there would now be a mismatch between the redirect URI that the Authorization Server saw in the Authorization Request and the one that the client uses towards the token endpoint. This attack is even more trivial if no redirect URI was pre-registered at all.

推理是此处规范安全考虑的一部分:https://tools.ietf.org/html/rfc6749#section-10.6

The reasoning is part of the security considerations of the spec here: https://tools.ietf.org/html/rfc6749#section-10.6

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

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.

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

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

客户端的重定向URI，带有一个受
控制的URI攻击者.然后攻击者诱骗受害者跟随
操纵链接以授权访问合法客户端.

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.

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

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).

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

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 RFC 要求再次传递 redirect_uri 以交换令牌代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！