17

I'm wondering what the reasons are for OAuth 1.0 to require a round-trip to the data provider to exchange an authorized request token for an access token.

My understanding of the OAuth 1.0 workflow is:

  1. Requesting site (consumer) gets a request token from the data provider site (service provider).

  2. Requesting site asks the data provider site to authenticate the user, passing in a callback.

  3. Once the user has been authenticated and authorized the requesting site, the user is directed back to the requesting site (consumer) via the callback provided which passes back the now-authorized request token and a verification code.

  4. The requesting site exchanges the request token for an access token.

  5. The requesting site uses the access token to get data from the data provider site.

Assuming I got that right, why couldn't the callback simply provide the access token to the requesting site directly in step 3, eliminating step 4? Why is the request to exchange the request token for the access token necessary? Does it exist solely for consumers that require users to enter the verification code manually, with the thought that it would be shorter and simpler than the access token itself?

Bosh
  • 8,138
  • 11
  • 51
  • 77
Joe Shaw
  • 22,066
  • 16
  • 70
  • 92

1 Answers1

16

Joe,

With OAuth 1.0, it's important to keep in mind which pieces are happening "server-to-server" and which pieces involve the browser ("user agent"). The "point" of OAuth, if you like, is to get a server-side access token and secret to the consumer's back-end server, without ever having the secret pass through the browser.

With this in mind: when a user authorizes a request token, the "callback" happens through the user-agent, via HTTP redirection. In other words, any data (i.e. a verifier code and the request token but NOT the request token SECRET) in the callback is "seen" by the browser. This is why an access token (and secret) can't be parameters of the callback step: these need to be communicated directly from server-to-server, not via the browser.

Bosh
  • 8,138
  • 11
  • 51
  • 77
  • 3
    This answer on another question goes into some detail on the matter: http://stackoverflow.com/questions/3584718/why-is-oauth-designed-to-have-request-token-and-access-token/3663351#3663351 – Joe Shaw May 23 '11 at 19:45
  • I'm probably missing something, but isn't the oauth_verifier and the oauth_token enough to get an access token? If so, the browser has both of these and could potentially get an access token. I'm looking at the diagram here as my reference: https://oauth.net/core/1.0/#anchor9. Also, when is the oauth_token_secret ever used? – johnnyodonnell May 03 '18 at 22:16