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