The OAuth Bible

I tried to make this as understandable as possible for any party reading it which means that the wording, references, and terminology used may not reflect that of a technical paper or resource. Excuse me if you may for I wish all to understand this, and not just those with a degree in understanding legal or technical jargon.

Table Of Contents

Terminology / Reference

• Signed / Signature
  • This is usually a joined string of (the base) Request Method&URL Query&Parameters (Sorted & Encoded) and then encrypted against the key (consumer_secret&token_secret) for the final signature. In some cases this may be the key, Plaintext, or may use simply the consumerSecret, RSA.
• Consumer Secret
  • Usually given by application as a secret token for starting the OAuth handshakes.
• Consumer Key
  • Key usually given along-side Consumer Secret for OAuth handshakes.
• Nonce / UID
  • Uniquely generated ID of a given length using the a-zA-Z0-9 charset, by default these are usually 32 characters long.
• OAuth Token
  • This is a token sent by the server or endpoint. It can refer to either the Request or Access token.
• OAuth Token Secret
  • This is a secret generally sent with the response for a certain token. Used for exchanges / refreshing.
• Query
  • URL Query String ?query=looks&like=this
• Parameter / Argument
  • These are snippets of information that have a name reference such as oauth_token="helloWorld" where oauth_token is the parameter or argument and helloWorld is the value.
• Plaintext
  • Signature Encryption Method, Plain Text, as in Human Readable Text such as this is.
• HMAC-SHA1 [W]
  • Signature Encryption Method, Secure Hash Algorithm (1) Method, Encrypted Text
• RSA-SHA1 [W]
  • Signature Encryption Method, Secure Hash Algorithm (1) coupled with a public and private key. You may have seen this being used for your Github account at one point, also in SSH.
• Service
  • Provider of information, data-source, or supplying use. Twitter is an example of a service.
• Signature Method
  • OAuth Accepted Encryption method, one of the following: PLAINTEXT, HMAC-SHA1, and RSA-SHA1.
• Value
  • Information in relation to something such as a parameter.
• URL / URI
  • Location on the internet or resource locator.

Signed Requests

Signing a requests is more than just the signature step, it also includes either the header or query creation step. In this step the Application takes all the information it has gathered and generated and places in a single string.

Some requests will use the OAuth header for this, and others will use another which is the URL Query. In this section, we will look at how the signature process should be handled and how each parameter should be used with references to flows.

Note: This section is in regards to OAuth 1.0

On the first leg of generating such a string we must collect all the required parameters and their values, some of these are used inside of the string directly and others in-directly through the encryption or encoding of the signature.

Signature Base String

Gathering the Method of the request, the URL of the request (or in the case of Echo the verifying credentials URL) and the Query String joined together by the & character would look like this raw (taken from this twitter page):

POST&https%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fupdate.json&include_entities%3Dtrue%26oauth_consumer_key%3Dxvz1evFS4wEEPTGEFPHBog%26oauth_nonce%3DkYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1318622958%26oauth_token%3D370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb%26oauth_version%3D1.0%26status%3DHello%2520Ladies%2520%252B%2520Gentlemen%252C%2520a%2520signed%2520OAuth%2520request%2521

Which is then encoded against a signing key which in some flows is different than others but is always a joining of the OAuth Consumer Secret and Token Secret once again by the & character like so:

Note: Sometimes in case of RSA and xAuth the signing key may only be the Consumer Secret with an & appended or not. For more insights check out lines 180& 186 of mashape-oauth/lib/oauth.js

kAcSOqF21Fu85e7zjz7ZN2U4ZRhfV3WpwPAoE3Z7kBw&LswwdoUaIvS8ltyTt5jkRh4J50vUPVVHtR2YPi5kE

Encoding the Signature

At last, we are able to encode our signature using these two strings of information. If you read the Terminology guide you would know that there are three ways we can do this. PLAINTEXT, HMAC, or RSA. Each method is slightly different from each other.

Here we ignore any encoding and simply pass along the Signature Key

This encoding method outputs our key into binary which we update our base with, which after this step gets Base64 encoded into it's final signature string:

tnnArxj06cWHq44gCs1OSKk/jLY=

On the more complex side of encoding and security we have the RSA method that we have to encode the generated private key against our Signature Base.

Note: Line 74 of mashape-oauth/tests/oauth.js may clear up how to use the generated private key to encode against the signature base.

Then on the service side they verify the public key that was generated along-side the private key against the encoded string passed as oauth_signature.

OAuth Header

The OAuth header is a part of the signed request, it contains the oauth_signature and oauth_signature_method parameters and their values. It is a single string and separated generally by a comma (spaces are supported here by some services, stick to comma by default unless told otherwise by the service) and named Authorization with OAuth being the Bearer, in other flows this may change such as the OAuth Mac Bearer and other similar methods.

The header itself is built up by all the oauth_* parameters sorted (by name, then some more complex things). Here is an example taken from Twitter for getting a Request Token:

POST/oauth/request_tokenHTTP/1.1User-Agent:themattharris' HTTP ClientHost:api.twitter.comAccept:*/*Authorization:
 OAuth oauth_callback="http%3A%2F%2Flocalhost%2Fsign-in-with-twitter%2F",
 oauth_consumer_key="cChZNFj6T5R0TigYB9yd1w",
 oauth_nonce="ea9ec8429b68d6b77cd5600adbbb0456",
 oauth_signature="F1Li3tvehgcraF8DMJ7OyxO4w9Y%3D",
 oauth_signature_method="HMAC-SHA1",
 oauth_timestamp="1318467427",
 oauth_version="1.0"

The oauth_callback is what twitter will invoke or respond to when the authentication step happens, some services tell you they have successfully confirmed this information with a oauth_callback_confirmed token (This should be the de facto situation).

Now, lets see the example response:

HTTP/1.1200OKDate:Thu, 13 Oct 2011 00:57:06 GMTStatus:200 OKContent-Type:text/html; charset=utf-8Content-Length:146Pragma:no-cacheExpires:Tue, 31 Mar 1981 05:00:00 GMTCache-Control:no-cache, no-store, must-revalidate, pre-check=0, post-check=0Vary:Accept-EncodingServer:tfe
oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0&
oauth_token_secret=veNRnAWe6inFuo8o2u8SLLZLjolYDmDP7SzL0YfYI&
oauth_callback_confirmed=true

Great, 200 response with the oauth_token, oauth_token_secret and oauth_callback_confirmed parameters. This is perfect, now you can use the oauth_token_secret for creating your signature for the access token and oauth_token for authenticating the request.

Generally, the oauth_token will be sent along as a query parameter ?oauth_token=[token goes here] on the authenticate endpoint if we were doing a three-legged OAuth 1.0a request which should give you back the oauth_token and oauth_verifier which then are used as well in your Access Token request [19].

OAuth 1.0a (one-legged)

What is commonly known as two-legged is actually one legged, there is only one step, thus you are standing on one leg.

Note: Google requires an unorthodox non-oauth parameter that must be added to the query string of the url you are request called xoauth_requester_id [R] this has also been deprecated in favor of OAuth2.

This is probably the most quickest method of consuming an OAuth implementation however it comes with a few drawbacks on security which you can assume for yourself whether it is the best for your application.

OAuth 1.0a (two-legged)

The real two-legged OAuth implementation, so lucrative it's like finding a diamond in the rough. Here we also avoid the user authentication step but follow the other flows of OAuth.

Here is the actual flow of OAuth 1.0a 2-legged, here we can see the extra security measures in place to make sure a secure access connection has been made without bothering the user to authorize details.

OAuth 1.0a (three-legged)

This flow is the full experience, the grand finale, the whole shebang. It's the full-flow of OAuth 1.0a, and the most complex, excluding the other two variants on it. The user interaction in the middle of the flow is usually what causes most confusion.

Note: In Step 6 if oauth_verifier has not been set, this is a failed OAuth 1.0a 3-Legged implementation and probably only requires the oauth_token to be sent. Rarely seen but they exist.

The most secure OAuth implementation so far, yet a little more complicated seeing as the user is a part of the handshake and must interact with interfaces during the transactions.

OAuth 1.0a (Echo)

Not necessarily the most common of OAuth implementations, but it exists. Created by Raffi from twitter it uses two extra headers in the initial request token step to validate your user on their behalf by delegation.

So essentially the Service (third-party, delegator) will authenticate and verify the user against the originating service such as Twitter (Origin Service).

OAuth 1.0a (xAuth)

xAuth is a way for desktop and mobile apps to get an OAuth access token from a user’s email and password, and it is still OAuth. So the third-party will ask for your credentials on the origin service to authenticate with.

The xAuth process will give back read-only, or read-write access tokens. Some limitations can apply, as in the Twitter spec Direct Messages read access is not provided and you must use the full OAuth flow (three-legged).

Note: The user's credentials should never be kept by the application requesting them.

OAuth 2 (two-legged)

By far the easiest to explain, here we have what is called a Client Credentials authorization flow. [26, 4.4] Which is also basically just the Resource Owner Password flow without the username and password appended to the encoded query passed along as the body, unless the service states through the url in which case is wrong.

Note If you are using basic, you will need to additionally pass along an Authorization header with the bearer type as Basic and as the value you use client_id:client_secret Base64 encoded.

Authorization: Basic Base64(client_id:client_secret)

Client Credentials

Resource Owner Password

Basically OAuth 1.0a Echo… without the signing and complications. Let's do this.

OAuth 2 (three-legged)

OAuth2 three-legged cuts out a lot of clutter just like the two-legged, no longer are things so complex with signing your requests.

Fun Fact: Scope by spec was to be space seperated (i.e. user pull-request) to which nobody followed and we are now left in a state of constant wonder as to what the next api we tackle uses.

OAuth 2 (refresh token)

In OAuth2 the access_token sometimes, which is most of the time, has a limited lifetime expectancy. We can assume by the expires_in parameter passed along at the Access Token response stage whether it will live forever or decay in a certain amount of time.

If an expired token is used the Service will respond with a Session expired or Invalid response error. This means we must use the refresh_token along with a few other previously obtained parameters to generate a new one. A lot easier than the whole flow.

Tips & Tricks

Generating Access Token & Refresh Key

Instead of encrypting information and using this as a sort of reversible string it's a lot more secure to simply utilize the same method of generation as the nonce string, a uuid. Randomly selected characters in a specific length.

Example

varOAuth=require('mashape-oauth').OAuth,access_token=OAuth.nonce(/* Length, Default 32 */);

Sources

Here is a long, windy list of places where I tracked down specific information regarding certain legs or auth specification excluding the original RFC and it's revisions.