What is OAuth 2.0?

First off, there's a lot of resources out there on what is the OAuth2 protocol and how it came to be. What I'm going to try to do is collect it all in this post including where it originated from and what's the future of it. Please feel free to comment if something is incorrect. After all, the best way to learn is to teach right?

If you want a TL;DR, as always scroll to the bottom.

So what is the OAuth2 protocol?

By definition, OAuth is a protocol that allows a resource owner to authorize clients to access a website or non-website server. This is important because it allows the resource owner to determine what areas the client can see which is convenient if you have proprietary or confidential IP. Typically, the authorization is granted via Access Tokens, an encrypted string that represents the granted permissions (or scopes). The API will then determine what scopes the client is authorized for and return back the data. For example, a Menu app would accept differing levels of authorization:

• creating item (scope read: item)
• deleting item (scope delete: item)
• updating item (scope update: item)

Within the OAuth 2.0 flow, there are the following roles that come into play.

• Client: The application that is requesting access.
• Resource Owner/Server: The entity that can grant access and the server that contains the protected resources.
• Authorization Server: The server that authenticates whether or not the authorization grant is valid. If valid, an Access Token is granted.

_{This is taken from Auth0's page on OAuth 2.0 which I would highly recommend for further learning.}

1. The Application (Client) asks for authorization from the Resource Owner in order to access the resources.

2. Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner's authorization.

3. The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.

4. Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.

5. The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.

6. Provided that the Access Token is valid, the Resource Server serves the Application's request.

This is a high level overview of the flow and each step can be explained in further detail, enough to constitute it's own page so I will remain general and elaborate into further detail in another page. However, an important aspect of OAuth 2.0 is to know how the authentication works.

So first off, there is a difference between authentication and authorization. Authentication means that the entity has been validated to be who it claims to be. Authorization on the other hand refers to rules that determine who is allowed to do what. A good example of this is if you think of an application as a house. Authentication would be the owner of the house allowing Bob to enter the house. Once you have proven that you are Bob, you will be allowed to enter. Authorization in this case would be the owner telling Bob that he may enter the kitchen but not the master bedroom.

Now that we have defined the two, it will make more sense that OAuth 2.0 is an authentication protocol although due to scopes, it has some pseudo authorization aspects too. How the authentication works is that the protocol has two endpoints: Authorization and Token. What happens is that once a client has requested access to the resource server, the server will redirect the client to a consent screen where credentials can be entered. Assuming the credentials are valid, the client is given a response token and redirected back to the original page. I am sure you are familiar with this, this can be seen in many login screens where you can "Login via Facebook" or "Login via Github". Both of those options redirect you to the prospective login pages where you authorize the client's permission to access and then you are redirected back to the client.

Depending on the Authorization flow, the response token can return back a Refresh Token as well. This is generally used by web applications that are server side so the source code is not exposed to the public. Since the code is not exposed to the public, in this flow the response token will contain client_secret, client_id, scope, state, redirect_uri, access_token and refresh_token. So much information is exposed in this flow to allow a client and the resource server to interact with less, if any, user interaction. Given that information, the client can call the Authorization endpoint and use the refresh_token to renew the access_token since typically the access_token has a shorter duration. For example, the access token can expire every 24 hours whereas the refresh token can expire every 100 days.

TL;DR

Honestly, there is a lot of complexities and intricacies of OAuth 2.0. But Auth0 did an incredibly good job of simplifying a generic flow so I will just post their diagram here. They explain a lot of concepts easily and I did my best to summarize the information in a single page here for ease of use.

Sources:

1. OAuth 2.0 Authorization Framework
2. What is OAuth?
3. Which OAuth flow to use?