OAuth 2.0 is the industry-standard protocol for authorization for web applications. OAuth 2.0 enables third-party applications (Clients) to have limited access to the protected resources of a resource owner without sharing any credentials by the owner with the client.
We will learn how OAuth 2.0 work in this post.
Video tutorials help in better learning. You must watch the video below. But it is always a good practice to read and understand the articles as well.
If you navigate to the Signup/SignIn page of applications like Spotify, you must have seen options like SignIn using Facebook or Google as shown below.
When you click on these options then you are navigated to the official Facebook and Google account page where you are required to log in with Facebook or Google account credentials. You can also create an account on Facebook and Google if you don’t have one. Once you fill in your credentials, you will be redirected to Spotify with a profile created (SignUp) or homepage (Log In).
You don’t actually share your Facebook or Google account credentials with Spotify. Facebook and Google also do not share your credentials with Spotify. If you see the above image of the Google Account sign in then you can see a statement as “To continue, Google will share your name, email address, language preference, and profile picture with Spotify.“. Once you give your consent by logging in then Google shares your name, email address, profile picture, etc. with Spotify. These details are used by Spotify to create your account on their platform.
Google uses OAuth 2.0 for all these flows.
Please note here that OAuth 2.0 is for Authorization, not Authentication. Authentication is the process of verifying who a user is and authorization is the process of verifying what they have access to. But you will be thinking that SignIn with Google on Spotify is Authentication. In fact, Google APIs use the OAuth 2.0 protocol for authentication and authorization. But in the end, Spotify needs to call Google APIs with resource owner consent to access resource owner details which is Authorization.
Let’s see another real-time example. Create an account on the CVS Photo Print website. If you want to print any photos then you can upload photos from your Computer or you can upload photos from Google Photos as well. When you click on the “Connect to Google Photos” link the same process as Spotify will be repeated.
I have captured this flow from the official documentation of OAuth 2.0. The below diagram shows the OAuth 2.0 authorization flow.
A Client ( Spotify in the above real-time example) requests authorization from the resource owner i.e. You. At this step, You will be redirected to the authorization server where you need to provide your credentials. As we are taking an example of Google, then you need to pass your Google account credentials. Here Authentication takes place. The client must be registered with Google before requesting authorization from the resource owner.
If the resource owner authenticates successfully then an Authorization grant will be received by the Client. An authorization grant is a credential representing the resource owner’s authorization. This Authorization grant can be anyone from Authorization Code, Implicit grant, Resource owner password credentials, and Client credentials.
The client requests an access token from the Authorization server using the Authorization grant received in step B.
The authorization server authenticates the Client and validates the authorization grant and issues the access token to the client if valid.
Client requests for the protected resource of the resource owner (who authorizes it in step A) from the resource server using the access token. For example, the client i.e. Spotify may request for resource owner’s name, email address, profile picture, etc. from the Google server using Google APIs so that Spotify can create your user account on their platform.
The resource server validates the access token and serves the request if the access token is valid.
From the above flow, you must have understood the roles involved. There are four roles involved in OAuth 2.0 flow –
- Resource owner – An entity capable of granting access to a protected resource.
- Resource server – The server hosting the protected resources that is capable of accepting and responding to protected resource requests using access tokens.
- Client – An application making protected resource requests on behalf of the resource owner and with its authorization.
- Authorization server – The server issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
We will learn about Authorization Grants and their types in the next post.
Thanks for reading. Kindly comment for any feedback and suggesuggestions.