How about this idea... Instead of the Request token --> Redirect to Service provider w/ token process how about just redirecting straight to the service provider with just the consumer ID in the URL.
1. User visits Consumer site and can optionally register an account. 2. Consumer registers account or pin with Service provider by making request. 3. User visits the generated URL from the consumer (ex. http://www.pictureland.com/oauth?consumer_id=<consumer ID>) 4. User authenticates with Service provider 5. User directed to consumer authorization page on Service provider where they must enter in the username or PIN for the consumer (more on PINs later) 6. User enters in username or pin # and clicks authorize (optionally can also select access restrictions for the consumer on this page also) 7. Service provider validates username / pin and if valid calls consumer callback URL with access token included 8. User redirected to consumer 9. Consumer can now use access token Pins: Allow for authorizing consumer access w/o having to create an account. Pin is generated by consumer and then registered with service provider. User must then copy and paste pin into authorization page on service provider. Here is a diagram displaying this process (using username method): http://i42.tinypic.com/2uqlimd.png So what is do you think? On Apr 24, 2:43 pm, Luca Mearelli <[email protected]> wrote: > On Fri, Apr 24, 2009 at 8:03 PM, Brian Eaton <[email protected]> wrote: > > > No, we haven't, and in fact we can't with the protocol as it stands > > today. Please go read Eran's blog post explaining the attack: > > >http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses... > > We haven't solved it completely (as in *made impossible*), but those > minimal additions to the protocol reduce a lot the available attack > window. I think that security work should at least seek improving > un-feasibility of an attack vector under given constraints. > > I read Eran's article before sending the first email of the long > thread, and I'm a bit lost in the whole discussion now, but I'd still > like to know if what I said there missed the point e.g. with regards > to the fact that the SP cannot safely pass information, like the > "unpredictable callback parameter", back to the consumer over the > redirect if the callback URL is not verified ... > > I hope this doesn't sound stupid or pedantic (I'm just trying to understand) > > Luca --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
