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 -~----------~----~----~----~------~----~------~--~---
