问题
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?
回答1:
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.
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.
The reasoning is part of the security considerations of the spec here: https://tools.ietf.org/html/rfc6749#section-10.6
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.
回答2:
The answer from Hans Z. seems correct from my reading of the spec. https://tools.ietf.org/html/rfc6749. I'll try an alternate explanation of the same content.
First, the authentication code flow from section 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)Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
The question is why step (D) requires the redirection URI.
Who owns what:
- Authorization Server is owned by Company 1
- Client is owned by Company 2, using Company 1's auth infrastructure to access the Resource Owner.
My Assumptions:
- (D) between Company 1 and Company 2 is secure (by some means, perhaps client_secret and TLS. The exact mechanism is left undefined in RFC)
- Client is not a resource specifically whitelisted by Company 1. This is an RFC recommendation but not a requirement.
Malicious Client Company 3 wants access to Resource Owner under the guise of Company 2.
- Company 3 inserts itself (BadClient) as a middleman between the User-Agent and Client Company 2 client.
- Fake Redirection URI points to BadClient Company 3 and shows fake pages. These pages trick the user to authenticate with Company 1 for Company 2 (client_id is Client2), and Company 3 successfully receives the authentication code because of the fake redirect (C). The user thinks the fake pages that Company3 created actually belong to Company2.
- The malicious client makes a (C)' request from BadClient to Client because it has received the authorization code on behalf of the user. for example, www.company2client.com?code=\&state=\, trying to get the accessToken that only Company 2 should have access to. The Client Company2 forwards the request along with its client_secret (only Company 2 knows this) and also its redirect_url (the question is why?) to the Auth server, and the access token is returned to (E) which is then passed back to the malicious client middleman. GAME OVER.
- To stop this attack, the Authorization Server can compare the redirection URL between (A) and (D). The redirect_url of the authorization request (BadClient) did not match the redirect_url provided in the access_token request (Client). Note that having a registered whitelist of redirect_urls would have solved this problem at the authorization request (A) but that was only a recommendation of the RFC, not a must have. Instead, RFC states that providing the redirect_url in (D) is the must have rather than mandate the whitelist.
回答3:
As described by user892703 in the last point. If the authorization step validates the redirect uri with the whitelist uris that the client registered during its registration phase then this resending of redirect_uri is not needed in the token obtaining step.
来源：https://stackoverflow.com/questions/29653421/why-does-oauth-rfc-require-the-redirect-uri-to-be-passed-again-to-exchange-code