OAuth 2.0 – What You Need to Know About It for Building Your Next App

Flatiron School / 7 November 2013

The following is a guest post by Manuel Neuhauser and originally appeared on his blog. Manuel is currently in the Ruby-003 class at The Flatiron School. You can follow him on Twitter here.

OAuth 2.0 is an authorization framework that allows applications to gain access to an HTTP service. It has become the de facto standard for users to share data from one website account with another website. You may have already used OAuth without even realizing it. The popular login options “Login with Facebook” and “Login with Twitter” are both utilizing the OAuth authorization process defined in RFC6749 — namely OAuth 2.0.

When building a web application, OAuth is making it easy for developers to tie in with other websites, though there are some terms that first need to be understood to comprehend exactly how access can be gained and granted.

Authentication is the process in which one user identifies herself based on some shared secret like a username and password or a token. Authorization, on the other hand, dictates the level of access an authenticated user has to any given resource. A token or hash (not to be confused with the Hash data-type) is merely a generated, hard-to-guess string of characters.

Token-based authorization such as OAuth has the advantage of eliminating the need for a user to share her password with a 3rd party app, allowing the user to restrict the level of access, and permitting the user to revoke access to her data.

In order to ensure security without compromising the ease of use, OAuth 2.0 requires that all communication is sent over an SSL connection.

Let’s look at a concrete example of how we can use OAuth to gain access to a users GitHub account within our app.

1. Register the application

First and foremost, we need to establish a trust relationship between our application MyAppand Github. This is done through means of using a shared client ID and client secret which is generated when registering our app with Github. When using these credentials in API requests, Github can properly identify the authenticity of our app.

2. Authorization request & grant

In order to initiate a request to gain access to certain data in the user’s Github account, we craft a special link in our application MyApp which, when clicked, will forward the user to GitHub with an authorization request. It looks like this:

When looking closer at the link, we see three parameters:

  • client_id – This is the secret shared identifier that Github has previously provided to us when we registered our app.
  • scope – It describes what resources our app wants access to. The available scopes are defined by Github.
  • redirect_uri – Tells Github where to send the authorization grant to.

Github will use these parameters to validate the authenticity of the request and find out what resources is requested. It presents a prompt to the logged in Github user asking whetherMyApp should be allowed to access a certain set of resources in their account. When the user agrees to grant access, Github will send an HTTP GET request to the redirect_uri and appends a code parameter with contains the authorization grant.

3. Access Token

Now that MyApp has the authorization grant, it can contact Github and request an access token, which is used for the actual API calls. To do that MyApp sends a POST request to Github including the client ID, client secret and the authorization grant code.

If Github’s authorization server receives valid credentials, it will respond with an access token. This access token allows MyApp to send API requests on behalf of the user for resources belonging to the previously defined scope.

4. Making API calls

At this point, MyApp can make API calls to retrieve information from the Github user account, and it is authorized with the access token. The access token can be put into either the header:

… or alternatively, added as a parameter to the API call URI:

Additional information

For a detailed breakdown of OAuth 2.0, I can highly recommend to read RFC6749, especially section 4 and 5.

Link Generation in ERB With Rails Previous Post I Like My Coffee Strong ... And My Params Stronger Next Post