> Can you explain how intercepting the authorization code > without having access to the client credentials is a > problem? For the sake of discussion, assume that the client > has valid and secure credentials that an attacker cannot > access. Also assume that the client has implemented some > form of cross-site protection.
One way: man-in-the-middle attack. The traffic between the legitimate user's browser and the client goes through the attacker's machine (easy to set up with a rogue WiFi access point). The user's browser sends an http request to the client, targeting the redirect URI. The attacker's machine doesn't let that request go through. The attacker then sends the same identical request from the attacker's own browser. When the client receives the request, it has no way to tell that it is coming from the attacker's browser rather than from the user's browser. The client exchanges the authorization code for an access token, uses the access token to obtain protected resources belonging to the user, and delivers those resources to the attacker's browser. (Or manipulates those resources as directed by the attacker's browser.) In the Facebook use case, the client logs the user in upon verifying that the authorization code is valid by exchanging it successfully for an access token. Another way (passive attack): The attacker observes the request from the user's browser to the client. The attacker does not stop the request. The client receives the request with the authorization code and exchanges the authorization code for the access token. Now the attacker sends the same request from the attacker's own browser. The client receives the second request and exchanges the authorization code for another access token. Upon receiving the second request for the same authorization code, the authorization server revokes the first access token, as suggested in section 4.1.2 of the specification: "If an authorization code is used more than once, the auhorization server MAY revoke all tokens previously issued based on that authorization code". The client then uses the second access token to access protected resources for the benefit of the attacker. In the Facebook use case, the attacker is logged in as the legitimate user. > I don’t know much about FB’s implementation but if they > allow the authorization code to be used for anything other > than exchanged for an access token using secure client > credentials, then they are not implementing the protocol as > specified. Facebook uses the protocol correctly, but the examples in the Facebook documentation use http rather than https for redirect URIs, so implementations that follow the examples use http rather than https. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
