I think it does solve the problem, Owen.
The SP redirects B to the malicious callback – and remembers that this malicious callback is associated with this request token & verifier. When the consumer asks for an access token the consumer will include the original callback. The SP notices that the two callbacks are different and rejects the access token request. James Manger [email protected]<mailto:[email protected]> Identity and security team — Chief Technology Office — Telstra _____ From: [email protected] [mailto:[email protected]] On Behalf Of Owen Evans Sent: Wednesday, 6 May 2009 11:09 AM To: [email protected] Subject: [oauth] Re: Confirm callback when getting access token Doesn't really solve the problem: (malicious) User A gets the "Authorisation URL" from an application that has received a request token. User A replaces call-back parameter with malicious or spoof site instead of original call-back User A tricks User B (Innocent) into logging into SP with incorrect call-back parameter. User B is sent to malicious site which save the verification code. User A gets verification code from malicious site and uses it to redirect to original consumer application User A now has access to User B's resources. O --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
