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 <[email protected] > <mailto:[email protected]>> wrote: > > > > > On Apr 24, 3:23 pm, joshthecoder <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > > > > > > On Fri, Apr 24, 2009 at 8:03 PM, Brian Eaton > <[email protected] <mailto:[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 -~----------~----~----~----~------~----~------~--~---
