Wiz of OAuth2.0

Many of us have been using different applications on a daily basis where we need to sign in or sign up whenever we need to use them. You might have the experience where the mere fact of having to register for a new account and password deters you from wanting to even use an application. I sure have many of those experiences. Having to register and manage new username and password for every new application you are using can be really inconvenient. What if there is a way for you to have your authentication on one of the applications you own to grant access to the third party application you are looking to sign up for without you having to enter new username and password. Wait you might have already seen that magic in works all pun intended. The magic of OAuth is what makes this process possible specifically OAuth2.0.

The OAuth was an authorization framework that got introduced in 2007. The main purpose was to provide an authorization mechanism for third party websites to have limited access to your private resource and information stored on your service provider without giving your credential away. The original OAuth was largely based on two existing proprietary protocols: Flickr’s authorization API and Google’s AuthSub. The general idea is that when you are trying to sign up for an application, there may be several options available for how you will sign up for your account. Some of the options may be to grant the application the access to your Google, Facebook, or Twitter account. You may choose one of these options because you won't need to enter username and password to create a new account. That's the use and purpose of OAuth.

However, OAuth required crypto-implementation which is a pain point for developers that want to implement the original OAuth. The cryptographic requirements of the protocol and the complexity of the original OAuth signatures were major implementation challenges for anyone coming from the simplicity of username and password authentication. Then came OAuth2.0 which was introduced in 2012. It is a complete rebuild from ground-up to replace OAuth therefore it is a completely new protocol that is not backward compatible with OAuth. The implementation challenges have been greatly resolved and it provides better end user experience. OAuth2.0 is an authorization framework that is widely used by major platforms such as Google and Facebook. The goals and purposes of the original OAuth are pretty much carried over to OAuth2.0.

There are four different roles defined in the workflow of the OAuth2.0 authorization process. They are resource owner, client, resource server, and authorization server. Resource owner is the entity that is capable of granting access to its private resources. This role pretty much refers to the user who owns the resources. The client is the third party application that the resource owner is trying to grant limited access to his or her protected account information. The client can be web, mobile, or desktop applications. The authorization server is responsible for authorizing the access to the client. When the authorization process completes successfully, an access token will be granted to the client. The resource server is the host of the account information for the user. It validates and authorizes the incoming requests by communicating with the authorization server.

The general workflow:

1. The client request authorization to access the service resources of the user.
2. The user authenticates and authorizes the request and the client receives the authorization grant.
3. The client requests for access token from the authorization server to access the protect information of the user by sending authorization grant and other authentications to the authorization server.
4. If the authorization grant is valid, the authorization server issues an access token to the client application.
5. The client application requests for access to the protected information from resource server by presenting the access token.
6. If the access token is valid, the resource server will grant access to the information the client is looking for.

The above workflow is for authorization code grant is for application running on web servers. Depending on the grant type the sequence of interaction may change. There are also three other grant types which are implicit, resource owner password credentials, and client credentials grant type.

Implicit Grant:
This is a simplified version of the authorization code grant type where the access token is being issued immediately without the process of having to exchange for authorization code to obtain the access token. This practice is generally not recommended because it is not as secure as having to authenticate authorization grant.

Resource Owner Password Credentials Grant:
For this particular grant type, the user's username and password are used directly by the client to request for access token from the authorization server. This grant type is only used with trusted client applications and should only be enabled if other grant types are not available.

Client Credential Grant:
This grant type is used outside the context of the user and when the client is also the resource owner. It's used by the client directly for getting access token of its own service account. This is useful when the client application wants to update or access its own information.

Conclusion:
More and more applications are adapting the use of OAuth2.0 framework as the signup mechanism for new users. Once the new users have signed up with their google or facebook account, they will be able to sign in with those accounts without having to keep track of the exact account name and password for these applications. It is a much quicker and convenient way for signing up for new applications. Sometimes new users might be turned away because they are having to input information for registering new account without having the option of choosing their google, facebook, or other applicable accounts for sign in. Having the option of choosing to signup with other existing accounts may be key in at least getting the users' feet in the door.

References:
https://www.oauth.com/oauth2-servers/differences-between-oauth-1-2/
https://en.wikipedia.org/wiki/OAuth
https://www.appknox.com/blog/how-oauth-works-how-to-ensure-a-secure-implementation
https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
https://oauth.net/2/