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 technical jargon.
Parameters, which is then encrypted against the key which consists of: (
token_secret). In some cases this may be the key, plaintext, or may use simply the
consumer_secret, for RSA encryption.
access_tokendepending on which step in the flow you are on.
?symbol, the keys and values are seperated by the
=sign and each data-store is seperated by the
oauth_tokenis the parameter or argument and
helloWorldis the value.
This section is in regards to OAuth 1.0
Signing requests is more than just the signature so 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.
In this step the Application takes all the information it has gathered and generated and places it in a single location.There are two ways of transporting this information, through the
OAuth header or
Query string. I highly recommend going the header route for better security.
Before we can generate this string we must gather 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.
Method of the request, the
URL of the request (or in the case of
OAuth Echo the verify credentials uri) and the
Parameters joined together by the
& symbol would look like this raw (example from twitter):
signature base string is then encrypted with a salt called the signing key which is always a joining of the OAuth
Consumer Secret and
Token Secret once again by the
& character like so:
Sometimes in case of RSA Encryption and xAuth the signing key may only be the
Consumer Secret with the
& symbol appended or not.
For more insights check out the following lines, #233 & #283 from the
mashape-oauth node module.
At last, we are able to encode our signature using these two strings of information. If you check out the terminology section you would find that there are three ways we can do this. PLAINTEXT, HMAC, and RSA Encryption. Each method is slightly different, and carry their own set of pros and cons.
Here we ignore any encoding and simply pass along the
Signature Key as human readable text.
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:
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
For clarification on how to pass your private key check out line #74 from the
mashape-oauth node module.
Then on the service side they verify the public key that was generated along-side the private key against the encoded string passed as
The OAuth header is a part of the signed request, it contains the
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
OAuth being the Bearer, in other flows this may change such as the 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_token HTTP/1.1 User-Agent: themattharris' HTTP Client Host: api.twitter.com Accept: */* 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"
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.1 200 OK Date: Thu, 13 Oct 2011 00:57:06 GMT Status: 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 146 Pragma: no-cache Expires: Tue, 31 Mar 1981 05:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0 Vary: Accept-Encoding Server: tfe oauth_token=NPcudxy0yU5T3tBzho7iCotZ3cnetKwcTIRlX0iwRl0& oauth_token_secret=veNRnAWe6inFuo8o2u8SLLZLjolYDmDP7SzL0YfYI& oauth_callback_confirmed=true
200 response with the
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.
oauth_token will be sent along as a query parameter
?oauth_token=[token goes here] on the authenticate endpoint when doing a
3-Legged OAuth 1.0a request which should give you back the
oauth_verifier which then are used as well in your Access Token request .
What is commonly known as two-legged is actually one legged, there is only one step, thus you are standing on one leg.
Google requires a custom parameter that must be added to the query string of the url you are
xoauth_requester_id [R] and many others.
However, they have depricated OAuth 1.0a in favor of OAuth2. So make sure you are up to date on service authentication protocols and quirky requirements as the following information may not always be all that is required.
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.
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.
oauth_token_secretto access protected resources.
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.
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.
oauth_token_secretto access protected resources.
On Step 6 if the
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.
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 will authenticate and verify the user against the originating service such as Twitter.
Along with two additional headers:
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 flow.
The user's credentials should never be kept by the application requesting them.
Along with additional parameters:
x_auth_permissionOptional; Scope of the requested token 
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.
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_secret Base64 encoded.
Authorization: Basic Base64(client_id:client_secret)
If you aren't using the
You will notice that we don't send the secret, this is actually the correct way of sending information; However, like all the other parts of OAuth there are services that don't follow this paradigm so in some cases it may be required. Also, the header should not be used in this case, and once again some services may completely ignore the specifications. Make sure to check the documentation of the service before assuming.
redirect_uriThis is a server-side Redirection URI hosted by the provider or yourself.
access_tokeninside of the
redirect_uri, surprisingly enough inside of a
#hashfragment (as some server side components cannot read this information). You may want to take time to extract other information that is sent along here such as:
stateOptional; If used in the prior step.
Basically OAuth 1.0a Echo… without the signing and complications. Let's do this.
It should look like this:
If you aren't using the
Authorization header, these must be passed as well:
Which would become:
OAuth2 three-legged cuts out a lot of clutter just like the two-legged, no longer are things so complex with signing your requests.
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.
stateOptional; Unique identifier to protect against CSRF 
scopeOptional; what data your application can access.
Example Authorization URL (Not-Encoded for Readability):
codeand exchanges it for an Access Token:
client_secretare valid the Service will invoke a callback on
redirect_urlthat contains an
access_tokento use in subsequent requests in various manners dependent on the Service.
Authorization: [Bearer] access_tokenheader string where
[Bearer]is the Header Authorization Bearer Name it could be Bearer, OAuth, MAC, etc…
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.
scopeOptional; Cannot have any new scopes not previously defined.
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.