+1 on Matt's solution below, with the following caveat and concern:
What about apps that send the user off to authorize the request token
and do not utilize the callback (i.e., non-web applications).
Primarily, these would be desktop applications and such that will send
the user to the authorization URL in a launched browser, but have no
means of calling back to the non-web app. and simply rely on the user
closing the browser and returning to the app. and indicating that
they've authorized it.
In this case, the OAuth Consumer could signal to the Provider through
server-to-server communication (e.g., through the request method) that
it DOES NOT support the callback, and instead the Provider should end
the UI flow by displaying a token ("authorization key") that the user
manually brings back to the Consumer which it then uses when requesting
the access token for that request token.
Thoughts?
On 4/23/09 1:31 PM, Matt Sanford wrote:
> Hi Mike,
>
> I have a proof of concept I think might be similar to this. It works
> like so:
>
> 1. When the consumer gets the request_token the provide the callback URL.
> » Note this is server-to-server communication, unavailable to the user.
>
> 2. The user is redirected to the service provider to authorize the
> application.
>
> 3. Once authorized the user is redirected the the callback URL with an
> additional callback_token parameter.
>
> 4. When requesting the access_token the consumer provides the
> callback_token.
> » If the request_token has a callback but the access_token request does
> not have the callback_token access is denied and the request token is
> invalidated.
> » If the request_token had no callback but the access_token request does
> access is denied and the request token is invalidated.
> » If the callback_token does not match the one on record access is
> denied and the request token is invalidated.
>
> By sending the callback in the server-to-server communication it is not
> available to the user/attacker. This is also a signed request so
> man-in-the-middle changes to the oauth_callback will be caught by the
> signature. The final step of checking the callback_token prevents other
> man-in-the-middle style attacks after the user has been returned to the
> consumer app. Does this sound like what you're suggesting?
>
> Thanks;
> – Matt Sanford / @mzsanford
> Twitter API Developer
--
Dossy Shiobara | [email protected] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
