Why is OAuth designed to have request token and access token?

Question

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.

Answer 1

For usability and security reasons.

From the Beginner’s Guide to OAuth:

https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5

... While mostly an artifact of how the OAuth specification evolved, the two-Token design offers some usability and security features which made it worthwhile to stay in the specification. OAuth operates on two channels: a front-channel which is used to engage the User and request authorization, and a back-channel used by the Consumer to directly interact with the Service Provider. By limiting the Access Token to the back-channel, the Token itself remains concealed from the User. This allows the Access Token to carry special meanings and to have a larger size than the front-channel Request Token which is exposed to the User when requesting authorization, and in some cases needs to be manually entered (mobile device or set-top box).

===

Note that this question is a dupe of

Why must we "change temporary credentials for token credentials" in OAuth?

If the explanation from the Beginner’s Guide isn't clear, then go read @npdoty's take on it .

Answer 2

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.