AFAICT there is no difference in the amount of state consumers need to maintain between OAuth 1.0, the signed callback proposal, and the approval URL verification proposal. There may be some good reason to prefer either signed callbacks or approval URL verification, but I don't think consumer state is such a reason.
Unless I'm missing something pretty major: is it true that consumers need to maintain more state for the signed callback proposal? Why? On Tue, May 5, 2009 at 6:26 PM, Breno de Medeiros <[email protected]> wrote: > > James, you made the best argument (in my view) of why we should stick > with the existing proposal, namely that the easiest way to preserve > statelessness is to implement a measure that results in XSRF > protection side effects. > > On Tue, May 5, 2009 at 6:21 PM, Owen Evans <[email protected]> wrote: >> true... must be in an after lunch stupor. >> O >> >> 2009/5/6 Manger, James H <[email protected]> >>> >>> 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] >>> 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 >>> >> >> >> > >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
