Actually, I'd like to claim that there's no real point to the verifier value.
The major fix in Rev 1A is in 6.3 -- that the Consumer MUST authenticate (by signing his request) when he gets an access token. That prevents a malicious RO-turned-Consumer (as in advisory 2009.1) from gaining access to the protected resources, since he can't authenticate as the Consumer to get an access token. On the other hand, there's still another flavor of 2009.1 there that 1A still doesn't address (even with the verifier): -- Bad Consumer (BGC) gets a request token from Service Provider and registers a callback -- BC gives the request token to Otherwise Good Consumer (OGC), whom the Resource Owner trusts -- OGC gets the Resource Owner to authorize the BC's request token -- SP calls the callback for this request token, calling sending the verifier to BC -- BC uses the verifier to get an access token and access the resources. I like to imagine BC=DoubleClick, OGC=Amazon. In order to address this latter attack, you would need the RO and the Service Provider to somehow agree on who the Consumer is for a given request token. There's no mechanism in the current document for that, but you could imagine adding a parameter (say oauth_consumer) that the RO uses to tell the SP what authenticated identity the Consumer provided. (NB: You can't let the Client set this field to some unauthenticated value, since then you've just got a longer request token.) --Richard On Wed, Jul 1, 2009 at 3:41 PM, Morten Fangel<fan...@sevengoslings.net> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
