Menu
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:
Requesting site (consumer) gets a request token from the data provider site (service provider).
Requesting site asks the data provider site to authenticate the user, passing in a callback.
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.
The requesting site exchanges the request token for an access token.
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?
286
The authorization code is a temporary code that the client will exchange for an access token. The code itself is obtained from the authorization server where the user gets a chance to see what the information the client is requesting, and approve or deny the request.
OAuth doesn't share password data but instead uses authorization tokens to prove an identity between consumers and service providers. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
Access tokens enable clients to securely call protected web APIs. Access tokens are used by web APIs to perform authentication and authorization. Per the OAuth specification, access tokens are opaque strings without a set format. Some identity providers (IDPs) use GUIDs and others use encrypted blobs.
After you add the authorization profile, you need to get access token from the server. In this tutorial, we get it by using the Authorization Code grant method: Click Get Token. In the subsequent dialog, enter Client Identification and Secret, Authorization URI, Access Token URI and Redirect URI.
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.
170
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
