So just to clear it up, our token flow would be: Get request token and direct user to service provider --> Authorize consumer and generate authorization token --> Consumer swaps authorization token for an access token
On Fri, Apr 24, 2009 at 11:31 PM, Josh Roesslein <[email protected]>wrote: > I believe this has been presented in a previous message. > > Instead of calling this "special value" a callback nonce it would probably > better to call it a "authorization token". > This way we don't get it mixed up with the oauth_nonce used to prevent > replay. > > This would prevent session fixation and by signing the authorization > request we prevent the callback from being tampered with. > > Compared with the solution I presented this would probably be easier to > apply. The way I specified does eliminate the need for the request token and > helps shorten the flow, but > would require some major changes. Perhaps this could be something we can do > in 2.0 spec. For a quick fix this idea would work and I don't see any > security flaws in it. > As long as the authorization token is random enough, the attacker can't > really guess it. > > > On Fri, Apr 24, 2009 at 9:36 PM, Zachary Voase > <[email protected]>wrote: > >> >> I'd like to propose the following flow (which is basically an >> amalgamation of a few ideas throughout this thread): >> >> 1) User visits Consumer's website, Consumer gets request token >> from Service Provider. >> 2) Consumer sends user to the Service Provider's user auth URL, >> with 'oauth_token' and 'oauth_callback' as before but also >> 'oauth_signature' and 'oauth_signature_method' parameters. >> Alternatively, 'oauth_callback' may be omitted if the Consumer has pre- >> specified a callback URL with the Service Provider. Both of these >> methods prevent the attacker from spoofing a callback. >> 3) User logs in to the Service Provider (if necessary) and grants >> access to the Consumer. >> 4) Service Provider generates a nonce, and if the callback was >> specified (with either the 'oauth_callback' parameter or when the >> Consumer signed up to the Service Provider), the User is redirected to >> the callback with 'oauth_token' and 'oauth_callback_nonce' parameters. >> If no callback is specified, the Service Provider gives the User the >> nonce to enter into their desktop application, etc. >> 5) The Consumer then attempts to exchange the old request token >> for a new access token, including the 'oauth_callback_nonce' in the >> parameters for this request. This exchange may only be attempted once >> for a single request token, after which it will any subsequent >> attempts with the same request token will fail unconditionally. In >> addition, the callback nonce must be present and correct. Since the >> attacker in the session fixation trick doesn't know this parameter >> (and indeed *cannot* know this parameter), (he/she/it) cannot attempt >> to get the access token (which would originally have been done by >> visiting the Consumer's callback URL). >> >> In the case of a desktop application, the User would have the callback >> nonce displayed to them by the Service Provider and would have to >> enter it manually into the application. The Service Provider has the >> responsibility of making it *crystal clear* to the User that this >> should be kept secret. It's a lot easier to get the User to keep the >> callback nonce a secret than it is to get them to think critically >> about the Consumers they authorize. >> >> Can anyone find a security hole in this workflow? >> >> Regards, >> Zack >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
