OAuth for the Confused August 28, 2017

While working on some code recently I ended up learning far more about OAuth than I ever wanted to know and so I thought I’d share my pain with the Internet.

This guide will cover OAuth 1.0a as that’s what I’ve been working with.

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

So, how does it work? We’re going to be covering things at a fairly high level as the fine technical details involve cryptography and other hairy things we probably don’t want to concern ourselves with.

Before we get started we’ll need a few things:

The aforementioned consumer is whatever is acting on behalf of the user. For example a Twitter client posting on behalf of somebody would be the consumer. Note that these are the credentials for authenticating the consumer and not the user.

The endpoints are simply the URLs that we’ll be sending data back and forth to at different stages of the process.

The process is broken down into the following steps:

  1. Obtaining a request token
  2. Authorising the request token
  3. Exchanging the request token for an access token

Obtaining a Request Token

The consumer uses their consumer key to identify itself to the OAuth service using the request token URL, and obtains a request token. This step is usually completely invisible to the user.

The purpose of the request token is to act as a kind of session identifier. We’re telling the OAuth service that we’re about to request authorisation on behalf of a particular user (we haven’t established who yet), and this allows the OAuth service to keep track of the process.

Now is a good time to mention signing. All token and protected resource requests are signed using an encoded version of both the consumer secret and token secret (of the request token or access token depending on the type of request). These secrets prove ownership of the corresponding consumer key and token.

Example HTTP request


Example HTTP response


Authorising the Request Token

Once a request token has been obtained, the user is redirected to the authorisation URL, along with the request token that was obtained in the previous step. This is the point at which the OAuth service learns which user it is that the consumer is acting on behalf of.

If the user isn’t already, they’re asked to log in and prompted to confirm that they actually wish to give the consumer access to the resource. This results in a verification code.

When we return from this step and move on to the next, the verification code is used to prove that we’re still dealing with the same user. The verification code is passed back to the consumer using either a callback URL provided by the consumer, or by simply displaying it and having the user manually enter it.

Example HTTP request


Exchanging the Request Token for an Access Token

Using the consumer key, the request token and the verification code obtained in the previous steps, the consumer can verify who it is, who it’s acting on behalf of and prove that it has permission to do so. This information is sent to the access token URL and a new token is returned. This is the access token and replaces the previously issued request token. The access token is used whenever the consumer is making requests on behalf of the user that require authentication.

Example HTTP request


Example HTTP response


Congratulations, you just did OAuth. If you want to find out more then I’d recommend reading the OAuth 1.0a specification; it’s not bad as far as specs go.