A Gentle Introduction to OAuth2.0

I have to admit, I am new to OAuth2.0. In this post, I will write what I have learned about OAuth2.0.

I don’t assume you have any idea of what OAuth is. I will do my best to make the explanation as simple as possible.

Additional resources are also provided.

First. What the heck is OAuth2.0?

OAuth2.0 is an authorization framework, the problem an authorization framework tries to solve is one dealing
with delegated access. Now, what does it mean to delegate access?

Suppose you want to edit your flickr photos with a third party application. Clearly, the third party application needs access to your photos. How do you give it access?

Using OAuth you can delegate access of your photos to the third party application.

In essense what you’re doing is authorizing the third party application to have priviledged access to your flickr on your behalf.

Before OAuth2.0 there was OAuth1.0.

OAuth1.0 is based on two proprientry protocols:

  • Flickr authentication API
  • Google AuthSub

This stackoverflow answer describes the some major differences between OAuth1.0 and OAuth2.0 very well.

Onward to discussing OAuth2.0.

OAuth2.0 roles

To understand the roles OAuth2.0 defines, let’s go back to our flickr example.

You as the end user of flickr, have a resource(your photos) that you want some third party application to access. Maybe you want to share them on facebook or edit them or whatever the application does.

In OAuth2.0 terminology, you are the resource owner and the photos on your flickr account are the protected resource. On the other hand, the third party application is the client.

The third party application(client) wants to access your flickr photos(protected resource), what mechanism does it
use to accomplish this?

To facilitate the client access to the protected resource, OAuth2.0 defines a new role. That of an authorization server(AS).

The authorization server provides the mechanism for the client to access the protected resource.

Those are the four roles OAuth2.0 defines:

  • Resource owner
  • Client
  • Protected resource
  • Authorization server

Access delegation

To further understand OAuth2.0 we need to look at how the four roles interact.

This calls for our first figure. Let’s go on an OAuth dance.

Let’s try to make sense of the Oauth flow.

  1. The client begins by requesting authorization from the resource owner. There are two ways the client can do this:

    1. Directly: What the figure shows
    2. Indirectly: The client uses the authorization server as an intermediary
  2. If the resource owner authorizes the client, an authorization grant is issued. There are four types of authorization grants:

    1. Authorization Code
    2. Implicit
    3. Resource owner password credentials
    4. Client credentials
  3. Using the authorization grant the client requests an access token from the authorization server.

  4. The authorization server authenticates the client and verifies the authorization grant issued by the client.
    If the authorization grant is valid, the authorization server issues an access token

  5. The client uses the access token to request the protected resource from the resource server.

  6. The protected resource server checks to make sure the access token is valid before giving the client access to the protected resource. If the access token is valid, the protected resource server will give the client access to the resource.

This is how the four roles interact with each other. It is the foundation of OAuth2.0 and hence, very important.

With this understanding you are equiped to explore OAuth deeper.

The next topic will be a discussion of the authorization grants available in OAuth2.0.