In the OAuth protocol, a service consumer will ask a user to authorize a request token in the service provider domain, then exchanges the request token for a access token from the service provider.
I'm wondering why OAuth is designed to have two tokens in the protocol.
Why not just use one single token in this process? That is, the user would authorize the token, and the service consumer would retrieve info from the provider with the token.
From The Official OAuth 1.0 Guide
The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.
An example use case is allowing printing service printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider) without requiring Users to provide their photos.example.net credentials to printer.example.com.
OAuth does not require a specific user interface or interaction pattern, nor does it specify how Service Providers authenticate Users, making the protocol ideally suited for cases where authentication credentials are unavailable to the Consumer, such as with OpenID.
OAuth aims to unify the experience and implementation of delegated web service authentication into a single, community-driven protocol. OAuth builds on existing protocols and best practices that have been independently implemented by various websites. An open standard, supported by large and small providers alike, promotes a consistent and trusted experience for both application developers and the users of those applications.
To sum up what that said basically the user gives a username and password to for an OAuth request token. You give the service that wants to connect to something using OAuth the request token and they receive the access token. This makes it so that the service never sees/uses the username and password.
I remember an awesome example about how to share a secret between two people if you live at 2 different locations. I have always thought this is how oAuth works.
Imagine Bob who lives in LA wants to send a secret message to Alice in New York. How would he do it so no-one could see whats in the box other than Alice.
Bob puts the message in a box and uses a normal padlock and key to lock the box. He then posts to Alice.
Alice receives the box, but she cannot open this padlock as she does not have a key. So Alice decides to put her padlock directly besides bob padlock (both padlocks are holding the box closed). She posts back to bob.
Bob gets the box back, uses his key that come with his lock and removes his padlock. And posts the box back to Alice.
Alice gets the box back with only her padlock on it, she uses her key to remove this lock. She can now see the secret message inside all the while "Eve" who works at the post office was never able to open it.
Whether not this is right, its a great concept in visualising some forms cryptography.
The message in the box is the secret oAuth key that is given to you so you can now interact with say Twitter.
The request token is designed to authorize the client (the provider authorizing the consumer's credentials). This is designed to allow the provider to prevent abuse, so that the provider can deny access to a client if it is misbehaving.
The access token is designed to authorize the resource owner (the end user).
OAuth provides a method designed to include two sets of credentials with each request, one to identify the client, and another to identify the resource owner. Before a client can make authenticated requests on behalf of the resource owner, it must obtain a token authorized by the resource owner. Section 2 provides one such method through which the client can obtain a token authorized by the resource owner.
This is as good an explanation as I've seen of how OAuth works, why it works that way, and why it's broken:
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars