I'll try to do my best to explain it. With callbacks there is, from a users perspective, no difference. After the user authorizes the app, the user is sent back to the consumer like http://consumer/post_authorize?oauth_token=x&oauth_verifier=y The consumer then makes a background-call to change the request -token for an access-token sending along the verifier. And you're done.
So there is no difference from the user perspective, except the one extra parameter on the callback url. From a security perspective the changes are extensive. Because the post_authorize url on the consumer cannot be "polled" with the token by a spoofer, because he won't know the verifier code. Only the user who was redirected from the SP and hence gave the permission will have the verifier. Without callbacks the SP after authorizations will now say something like "You can now go back to your app, punch in the verifier YYY and hit OK" instead of the old "You can now go back to your app and hit OK". The app then has an input field for the verifier code, and after proceeding it will exchange the request-token for an access-token while sending in the verifier code. -- Did that clear it up for you? -Morten On Jul 1, 2009, at 9:01 PM, Kelvin wrote: > > So does that mean the following oauth_verifier will be sent to > Consumer and User for User to manually verify the call back? I'm > confused how oauth_verifier works with / without callback value. Can > someone explain in more detail how it supposes to work ? thanks. > > > "After the User authenticates with the Service Provider and grants > permission for Consumer access, the Consumer MUST be notified that the > Request Token has been authorized and ready to be exchanged for an > Access Token. If the User denies access, the Consumer MAY be notified > that the Request Token has been revoked. > > To make sure that the User granting access is the same User returning > back to the Consumer to complete the process, the Service Provider > MUST generate a verification code: an unguessable value passed to the > Consumer via the User and REQUIRED to complete the process. > > If the Consumer provided a callback URL (using the oauth_callback > parameter in Section 6.1.1 (Consumer Obtains a Request Token) or by > other means), the Service Provider uses it to constructs an HTTP > request, and directs the User's web browser to that URL with the > following parameters added: > > oauth_token: > The Request Token the User authorized or denied. > oauth_verifier: > The verification code. > > The callback URL MAY include Consumer provided query parameters. The > Service Provider MUST retain them unmodified and append the OAuth > parameters to the existing query. > > If the Consumer did not provide a callback URL, the Service Provider > SHOULD display the value of the verification code, and instruct the > User to manually inform the Consumer that authorization is completed. > If the Service Provider knows a Consumer to be running on a mobile > device or set-top box, the Service Provider SHOULD ensure that the > verifier value is suitable for manual entry. " > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
