I have explained the Flow of OAuth 2.0 in the previous post. In Step B – Receive Authorization Grant, I mentioned that when A Client requests authorization from the resource owner and the resource owner authenticates successfully then an Authorization grant will be received by the Client. We will learn more about Authorization grants and their types 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.
The authorization server is an important role in OAuth 2.0 flow which provides an access token to a client by receiving and validating an authorization grant. An authorization server is an intermediary between a client and a resource owner.
Let’s try to understand this with an example. If you want to signup/in on Spotify with your Google account then Spotify navigates you to the Google account page where you need to provide your Google account credentials. This page acts as an authorization server for Google here.
The client needs to register with the authorization server so that the client can direct the resource owner to an authorization server instead of requesting authorization from the resource owner directly.
The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.
An authorization grant is a credential representing the resource owner’s authorization. The client can use the received authorization grant to get an access token from the authorization server. Once the client receives the access token then it can access the resource owner’s protected resource. So you can understand here that getting the Authorization grant is the starting point.
There are four types of Authorization Grants:-
- Authorization code
- Implicit Grant
- Resource Owner Password Credentials
- Client Credentials
The client directs the resource owner to an authorization server. Then the authorization server authenticates the resource owner and obtains authorization. After this client is redirected to the client with an authorization code.
Since the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client.
An example is as below –
https://localhost:8080/?state=state_parameter_passthrough_value&code=4/0AWgavdfoNkUkCHma6g1lO9-yjKYlJNrYylO7fRE_shjJK1AGLEkZrttKPpXh1Nw5WeYmj7KA&scope=https://www.googleapis.com/auth/drive.metadata.readonly
The authorization code has the ability to authenticate clients and safer transmission of the access token to the client.
The implicit grant is a simplified authorization code flow in which an access token is issued directly instead of an authorization code. It is optimized for clients implemented in a browser using a scripted language like JavaScript. The grant type is implicit, as no authorization code is issued.
When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. The access token can be exposed to other applications and resources owner in this flow. But it improves the efficiency and responsiveness of clients as there is no extra step to obtain an access token.
It does not support the issuance of a refresh token.
The Microsoft identity platform supports the OAuth 2.0 implicit grant flow.
The credential i.e. username and password of the resource owner is used as an authorization grant to obtain an access token. This grant type is suitable where the resource owner has the highest trust level with the client.
The resource owner provides its credentials to the client which is used by the client to obtain an access token from the authorization server. The client must authenticate itself with the authorization server.
So resource owner’s credentials are used a single time to obtain a long-lived access token or refresh token. There is no need of storing the resource owner’s credentials for future use.
In this type, Client credentials are used as an authorization grant. In the previous type, the resource owner’s credentials are used as an authorization grant. This is useful when the protected resources are under the control of the client or the client is also the resource owner.
Thanks for reading. Kindly comment for any feedback and suggestions.