I guess we could still support the current 1.0 spec for these sort of devices that need the request-token flow. When a consumer registers they can specify if they require 1.0 support. Consumer websites should not leave this enabled to prevent session fixation attacks.
On Sat, Apr 25, 2009 at 4:14 PM, Allen Tom <a...@yahoo-inc.com> wrote: > Proprietary auths like Yahoo's BBAuth and Google's AuthSub do not have the > concept of a request token, and instead just have the Consumer redirect the > browser to the SP's auth endpoint. After the user grants permission, the > user's browser is redirected back to the consumer with a token that is then > exchanged for the credentials. Neither BBAuth nor AuthSub are vulnerable to > the session fixation attack. > > Implementing the Request Token on the SP side of things is pretty tricky, > especially if the SP is globally distributed, as that requires the Request > Token to be replicated everywhere the user's browser and the consumer could > be located (which could distant from each other). The RT may also be tricky > for the Consumer, because improperly implemented consumers may implement > "early binding" and bind the Access Token with the Request Token, instead of > binding the Access Token with the callback token. > > On the flip side, eliminating the Request Token will exclude Consumers that > aren't able to redirect the browser from the OAuth flow. It might make sense > to just define an alternate flow for internet refrigerators and chumbys, > while optimizing for the 99% case, in which the consumer is either a website > or an installable client, on a system with a browser. > > That being said, it's probably easier and faster to do a minor tweak to the > existing spec, rather than define an entirely new flow, even if the new > RequestToken-less flow is essentially the same as what many proprietary > auths have been doing for years. > > Allen > > > Josh Roesslein wrote: > > Yes it eliminates the request token and basically skips to step D. I don't > really see the need for request tokens. > We can just direct the user to the service provider's URL for the consumer, > authenticate, and return the access token in the callback. > in the callback that is given when the consumer was registered. Could also > support dynamically setting callback by including > it in the authorization URL and signing it. > > The flow would be: > User visits consumer --> Consumer directs user to authorization URL --> > User authenticates with service provider --> Grant access to consumer --> > Directed back to consumer with access token > > By not having request tokens, an attacker can't really get into the flow. > There are two issues: > > 1. Service providers and Users must watch out for bad consumers that > register with the service provider. This can be avoided by > proper screening by the service provider (make sure the consumer is > legit) and the User knowing the consumer they are granting access. > > Example: > > - Attacker sends user this link: > http://www.serviceprovider.com/oauth/authorize?consumer=badconsumer.com > - User authenticates and grants access > - Directed to bad consumer site with access key > - Bad consumer steals private data with access key > > To fix attack: > - Delete consumer account on service provider > - Invalidate all access tokens generated by this consumer account > > 2. The token can be stolen by a man in the middle attack during the > callback. This can be avoided by using https. > > On Fri, Apr 24, 2009 at 4:59 PM, pkeane <pjke...@gmail.com> wrote: > >> >> >> >> On Apr 24, 3:23 pm, joshthecoder <jroessl...@gmail.com> wrote: >> > Actually after some more thought I have come up with this new >> > revision: >> > >> > 1. User visits authorization URL that directs them to the service >> > provider's site. >> > This link can be provided by the consumer. >> > Example: >> http://www.pictureland.com/oauth/authenticate?consumer=printit.com >> > 2. User authenticates with service provider. >> > 3. User authorizes access to the consumer. Optionally this page can >> > also be used >> > for setting other restrictions (ex. lifetime of token, resource >> > access rights, etc) >> >> Am I correct in characterizing #2 & #3 as collapsing the OAuth A & B >> steps into one interaction. Or perhaps more accurately, eliminating >> step A (getting a request token that will need to be authorized) and >> going right to B & C? >> >> --peter >> >> > 4. Service provider generates access token (only usable by the >> > consumer) >> > 5. User redirected to consumer URL with token attached. >> > Example:http://www.printit.com/oauth/regiser?token=12345 >> > 6. Consumer can optionally have user login and bind token with the >> > account >> > OR >> > Create session cookie stored in browser and token is bound to this >> > session. >> > 7. Consumer can now use token to access protected resources. >> > >> > This way the service provider does not have to manage consumer account >> > <--> service account relationships. >> > It simply generates a token for a specific consumer and then redirects >> > user with token to consumer provided URL. >> > It is now up to the service provider to bind this token to an account >> > or session. >> > >> > To prevent man in the middle attack of stealing this token, this >> > callback URL should use SSL. >> > >> > On Apr 24, 3:07 pm, joshthecoder <jroessl...@gmail.com> wrote: >> > >> > > 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 <luca.meare...@gmail.com> wrote: >> > >> > > > On Fri, Apr 24, 2009 at 8:03 PM, Brian Eaton <bea...@google.com> >> 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
