Beginners guide to OAuth 2.0

What is OAuth?

OAuth is an open standard that facilitate Internet users to allow websites and applications to access their information without giving them the passwords.  As a simple example, consider Facebook using OAuth so that a Facebook user can tell Facebook "I know this third party web service, allow it to view my profile".

The following is a sample prompt from Facebook which you might be already familiar with:

OpenID is another similar standard. The basic objective of Oauth is to provide authorization whereas OpenID is there to provide authentication. What does that mean?

Authentication vs authorization

Authentication is focused on proving the identity of a person or a resource whereas authorization deals with confirming the privileges that person or resource has. Simply put, authentication is about who somebody is and authorization is about what he is allowed to do.

OAuth is all about dealing with employees trying to enter into the building.

Now let's take a look at the current situation of OAuth.

What is OAuth 2?

OAuth 2 is the second version of OAuth. However, version 2 is not backward compatible with version 1 and it focuses more on developer simplicity. OAuth 2 has expanded its wings to support non web applications, which was considered as a limitation of OAuth 1.

How does OAuth 2 work?

The following represents the abstract protocol flow in OAuth.

Source: Digital Ocean

But the above is useless (a moo point as Joey would say) if you don't know about the OAuth roles.

OAuth Roles

1. Resource owner (User) - The user that the account information belong to. He authorized an application to access their account.
2. Client Application - The application that wants to access the user's account.
3. Resource / Authourization Server (API) - The resource server is the one that maintains the user's account. The authorization server is the one that checks the accessibility and grant access to required parties.  

In an example where you tell Facebook, "I know this XYZ service, allow it to view my profile.", you are the Resource Owner, XYZ is the Client Application and Facebook is the Resource/ Authorization Server.

Now the abstract protocol flow makes some sense, doesn't it?

1. The application asks the user's permission to call the resource server.
2. The user grants permission - there are multiple ways this grant can be allowed, which will be explained next.
3. The application shows the server "Hey look, I have the permission, let me in".
4. The doorman of the server checks the permission and gives an access token to the application "Okay, you can go in, show this access token when you're inside".  
5. The application goes in, and shows the access token to the one that keeps the information he wants.
6. The information is provided to the application.

This SO answer gives an interesting explanation about how OAuth2 works.

OAuth 2 Grants

In the above scenario, when the application asks the user to give access to the account information, the user could decide on how to give the required permission. So basically, a grant is a method of acquiring an access token. An access token always have an expiration time and it is usually accompanied by a refresh token, who is there to help refresh the access token when it is expired.

OAuth 2 supports 4 grant types:

1. Authorization Code grant - This is optimized for server-side applications and you may have already met this if you have ever signed into an application using Facebook or Google. This can maintain the confidentiality of the client-secret.
2. Implicit grant - This is different from the above because this is mostly used in mobile or single-page web applications, where maintaining the client-secret is a problem. In this method, the server returns an access token (instead of authorization code like before) and the server does not return a refresh token.
3. Resource Owner Password Credentials grant - This is used only if the application is trusted by the user and the user provides the credentials (username and password) which are used to obtain the access token.
4. Client Credentials grant - This grant type allows an application to access its own service account on the server. This is typically machine-to-machine authentication where user's permission is not required.

Which grant should I use?

If you're the client application developer, this is the obvious question that would hop in your mind. In his blog post, Alex Bilbie explains how to decide on which grant type to be used, based on the client type you're using and other factors. 

Source: Alex Bilbie

Cheers!