Introduction to OAuth 2.0
Before moving into the Introduction of OAuth 2.0 first look into some important concepts that we need to understand.
- Authentication is the process of identifying and validating that a user or an application who they claim to be. Username and Password is the most common authentication factor and if the provided username and password credentials are matches with the system data, system grants access to the user.
- Authorization happens after the user has been successfully authenticated. Authorization is the process of giving full or partial access to specific resources and functions of the system based on the user’s access rights. Basically, authentication is who you are and authorization is what you can do.
- Access Delegation is the process of authorizing an application with limited access to the user’s resources on behalf of a user. A real-world example of access delegation is the valet key of a car. Although a master key of a car supports all the functionality of the car, the valet key of a car only provides limited access to the necessary parts of a car, like a driver side door and engine start which are only needed to park the car.
Why OAuth?
In earlier days, if you wanted to use a third-party application that required access to another application's resources, you had to provide login credentials(username & password) of this application to the third-party application. But in that case, the third-party application has gained full access to the application using the login credentials you entered, and this third-party application can easily act like you. This third-party application can store your password credentials and keep using them. So this method is not acceptable from the security perspective.
Several solutions have come up to address this issue and OAuth is one of them. OAuth provides secure access delegation by providing a temporary token with limited access, instead of sharing the login credentials to the third-party application.
What is OAuth?
“The OAuth authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.”
Simply OAuth is an industry-standard protocol used for authorization and secure access delegation. There are two versions of OAuth, OAuth 1.0 and OAuth 2.0 and they have different specifications and there is no backward compatibility between these two versions. So which is the most popular OAuth version? OAuth 2.0 is the most widely used OAuth protocol today and let’s look deeper into OAuth 2.0.
Roles of OAuth 2.0
There are four key roles involved in the standard OAuth2 flow.
- Resource Owner: This is the owner(entity or person) of the resources in the resource server who is capable of granting access to the protected resources. If the resource owner is a person, it is called an end-user.
- Resource Server: This is the server where the resource owner stores his protected resources.
- Client Application: This is the third-party application that wants to access the protected resources in the resource server on behalf of the resource owner. The resource owner must give the necessary permissions to the third-party applications (client applications) to access the protected resources.
- Authorization Server: This is the server that authenticates the resource owners using their credentials. Authorization Server issues access tokens to the client application after successfully authenticating the resource owner. This access token is the credential gives to the client application to access the resource owner’s protected resources in the resource server.
Abstract OAuth 2.0 Protocol Flow
Let’s look into Abstract OAuth2 flow, which helps you to understand how oauth2 works. This flow explains the interactions that happen among the above-mentioned roles in OAuth2 Flow and it consists of 6 main steps as follows.
- The client application sends an authorization request to the resource owner(end-user) to gain access to the user’s protected resources.
- If the Resource Owner was not already authenticated with the authorization server, he will be required to log in and authenticate with the authorization server. After successful authentication, the user has to authorize the client application’s request. If the user approves the authorization request, the client application receives an authorization grant.
- Then the client application authenticates with the authorization server and requests an access token from the authorization server by providing the authorization grant, which was received in the last step.
- Authorization Server validates both the client application and authorization grant and then sends an access token to the client application.
- Then the client application requests the resources from the resource server by sending the access token which was acquired in the previous step. Client applications can use this access token multiple times until the token expires.
- Finally, the Resource Owner validates the received access token and if the access token is valid, returns the requested resources to the client application.
As I earlier mentioned this is the abstract Auth2 Flow. The real-world flow can differ with the Authorization Grant Type. The grant type is the mechanism used by the client application to get access tokens from the authorization server.
I hope now you have a clear picture of the OAuth 2.0 and let’s deep more into OAuth 2.0 in the future. Feel free to post your feedback in the comment section and Thank you for reading! 😃