Introduce OAuth 1.0

OAuth 1.0 is the standardization and combined wisdom of many well established industry protocols at its creation time. It was first introduced as Twitter’s open protocol. It is similar to other protocols at that time in use (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, etc).

Authlib implemented OAuth 1.0 according to RFC5849, this section will help developers understand the concepts in OAuth 1.0, the authorization flow of OAuth 1.0, and etc.

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirection.

Here is an overview of a typical OAuth 1.0 authorization flow:

OAuth 1.0 Flow

OAuth 1.0 Flow

Let’s take your mobile Twitter app as an example. When a user wants to send a tweet through your application, he/she needs to authenticate at first. When the app is opened, and the login button is clicked:

  1. Client uses its client credentials to make a request to server, asking the server for a temporary credential.

  2. Server responds with a temporary credential if it verified your client credential.

  3. Client saves temporary credential for later use, then open a web view (browser) for resource owner to grant the access.

  4. When access is granted, Server responds with a verifier to client.

  5. Client uses this verifier and temporary credential to make a request to the server asking for token credentials.

  6. Server responds with access token if it verified everything.

And then Client can send tweets with the token credentials.

Roles in OAuth 1.0

To understand above flow, you need to know the roles in OAuth 1.0. There are usually three roles in an OAuth 1.0 flow. Take the above example, imagining that you are building a mobile app to send tweets:

  • Client: a client is a third-party application. In this case, it is your Twitter application.

  • Resource Owner: the users on Twitter are the resource owners, since they own their tweets (resources).

  • Server: authorization and resource server. In this case, it is Twitter.

OAuth 1.0 in HTTP

Let’s explain OAuth 1.0 in HTTP one more time. The first step is:

Client uses its client credentials to make a request to server, asking the server for a temporary credential.

It means we need to ask a temporary credential from Twitter. A temporary credential is called request token in Twitter. The first request is (line breaks are for display purposes only):

POST /oauth/request_token HTTP/1.1
Authorization: OAuth

And Twitter will response with a temporary credential like:

HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded


Our Twitter client will then redirect user to the authorization page:

On this authorization page, if user granted access to your Twitter client, it will redirect back to your application page, e.g.:

And the final step is here, use the temporary credential to exchange access token:

POST /oauth/access_token HTTP/1.1
Authorization: OAuth

If everything works well, Twitter would response with the final access token now:

HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded


You can use the oauth_token and oauth_token_secret for later use.