Understanding the need for OAuth2

Why was OAuth2 needed

Consider an example where you are booking rooms at a hotel using some website.

The website offers you a discount of 20% if you allow them to access your gmail contacts so that they can send some marketing emails to them. You accept their offer. But how will you share your gmail contacts with them.
Previously the way this was done was you had to share your gmail credentials with the hotel booking website and then they would send the marketing emails to your contacts by login to your gmail account with these credentials and sending the marketing emails. This not a hypothetical situation.
Below is the screen shot of Yelp which is a popular online directory for discovering local businesses ranging from bars, restaurants, and cafes to hairdressers, spas, and gas stations.

Previously it would ask for the users email credentials and use them to send mails. This is known as password antipattern. What if there are security leaks at Yelp and your credentials were compromised. Using the gmail credentials unauthorized persons can access our google wallet, google drive and other services. So obviously sharing credentials is not a good way to allow a third party website/app to access your contacts.

How OAuth2 solved the problems

Soon many services realized sharing of passwords is not the right way and began devloping ways by which a third party website/app can be allowed to access certain protected data like email contacts. Many services implemented things similar to OAuth 1.0. Flickr's API used what was called "FlickrAuth" which used "frobs" and "tokens". Google created "AuthSub". Facebook opted to issue each application a secret, and require the application sign each request with an md5 hash with that secret. Yahoo created "BBAuth" (Browser-Based Auth). The result was a wide variety of solutions to the problem, completely incompatible with each other, and often failing to address certain security considerations.

Soon realizing their requirement was the same and not in anyway related to their business, these companies started to jointly develop an open source specification which would allow apps to be authorized to access protected data without sharing of passwords. By August 2007, the first draft of the OAuth 1 spec was published. Later there were various versions of the OAuth and the current version is OAuth2 which has become an industry standard. OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.

How OAuth2 works

The actors involved in OAuth2 are -

• User
• Client
• Resource Server
• Authorization Server

OAuth 2 is used for Authorization or Authentication

As we saw earlier the origin of OAuth was developed for strictly authorization purpose. Example using OAuth2 we can authorize websites/apps like Yelp to access our email contacts without sharing of passwords. However OAuth2 has evolved further and along with OpenId it is used for both Authorization and Authentication. So OpenID is built on top of OAuth2. OAuth2 determines whether a website/app can get access to protected data while open id determines whether the user is actually who they claim to be. And yes, both this authentication and authorization is done without sharing of credentials by the user. For example in this documentation google explains how it uses OAuth2 for both authentication and authorization.

Types of OAuth2 flows

• Authorization Code Grant
• Implicit Grant
• Password Grant
• Resource Owner Client Credentials Grant
• Refresh Token Grant