Access delegation via OAuth 2.0
What is OAuth2?
“OAuth is an open-standard authorization protocol, Which provides the client application with secure and delegated access”
Initially, we start with the basic authentication flow,
Let's describe the basic authentication flow with the example,
The user needs to get his photo already uploaded in the google drive. First, the user login into the system using his personal credentials(username and password). If the credential is correct then the google allows the user to access the google drive. There are no issues arise in this flow.
Let’s consider someone is going to use your information on behalf of you. Are you willing to provide your personal credentials to other third party applications? The answer is always NO.
How these applications access our information without our credentials? Here the OAuth protocol comes into the picture. The OAuth allows third-party applications to provide some limited access to get the service on behalf of the user. It uses a kind of token called “access tokens” instead of username and password.
Roles
Basically, there are four peoples play major roles in OAuth protocol,
- Resource owner: The person who is going to give some portion of access from their account. eg: the user who is going to use that application.
- Client: The third party application that is attempting to get access on behalf of the resource owner. eg: it can be any third party mobile or web application.
- Authorization server: This is the place where the resource owners store their credential resources and the place where you are authenticated. eg: Google, Facebook etc.
- Resource server: This is the place where the resource owners store and access their actual resource. eg: Dropbox, GoogleDrive etc.
How OAuth works
In the below diagram, the user wants to know that “Will he have a love marriage or arranged marriage ?” using a third-party application. For the analysis, the third-party application needs the user’s friend list from facebook. But the problem is the user doesn’t like to share his facebook credential with that third-party application. So the OAuth comes into the picture and the below diagram that illustrates the flow of access delegation via OAuth.
Step 1: The Resouce owner (user) request for service from the client (third party application)
Step 2: The Client (third-party application) sends the access request with its own identification and Scope to the authorization server ( facebook). Scope includes the access limitation (friend list of the resource owner) to the client.
Step 3: Authorization server (Facebook) gets the authentication request and verifies the identification of the third party application. After verification, authorization server requests to the resource owner(user) to authenticate them self and get consent to allow the client (third-party application) to access their resources mention in the concent interface.
Step 4: After getting positive consent from the resource owner, the authorization server sends the token to the client application for access the resource server. The token that sends by the authorization server belongs to the client request grant type(third-party application request).
Step 5: Client (third-party application) sends the resource request with the access token to the resource owner for accessing the resources(friend list of the user).
Step 6: Now the resource server validates the access token with the authorization server (facebook). If the access token is valid and not expired then the resource server gives access to the client(third-party application) to use the resource (friend list) until the access token expired.
In this flow, we need to concentrate on two major parts.
1. Grant type
Based on the client and their requirements, the client can choose their grant types. In general, there are five major and well-defined grant types available in the OAuth.
- Authorization Code — The authorization code grant type is optimized for confidential clients. It provides a few important security benefits such as the ability to authenticate the client and transmission of the access token directly to the client without passing it through the resource owner’s user-agent and potentially exposing it to others (including the resource owner).
- Implicit — It is mainly used for clients that are not capable of keeping the client’s own credentials secret.
- Password — The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client (e.g., a service’s own mobile client) and in situations where the client can obtain the resource owner’s credentials.
- Client Credential — This grant is suitable for machine-to-machine authentication or for a client making requests to an API that does not require the user’s permission. This grant should be allowed for use only by trusted clients.
- Refresh Token — The refresh token grant can be used when the current access token is expired or when a new access token is needed.
2. Token
- Access Token: This is the token that uses by the client application to access the resource owner. It will expire after certain minutes. We can get the access token using any of the grant types mentions above.
- Refresh Token: This is the token that uses by the client to get the new access token when the access token expired. It has a longer period of life compared with the access token.
The diagram describes the flow of getting access token using the refresh token.
After the client sends the request for service, the client will validate the access token that already has with the resource owner. From the response code sent by the resource server, If the access token has expired then the client uses the refresh token and send an access token request to the Authorization server using the Refresh Token grant type. If the refresh token is valid then the authorized server sends a new access token to the client. The client can use the new access token and send a fresh resource request and continue their service without any interruption.
Note: If the user wants they can have a facility in OAuth to revoke the access token and refresh token by sending a revoke request to the Authorization server. After revoking the client cant access the resources using Access token and also they cant generates their new access token using the refresh token.
OAuth 1.0 vs OAuth 2.0
OAuth 2.0 is completely different from OAuth 1.0 by the structure and the performance wise. Nowadays most of the application use OAuth 2.0.
The OAuth 1.0 use only three flows and also we didn't scale. OAuth 1.0 has cryptographic requirements. It is hard to implement.
On the other hand, OAuth 2.0 has six flows. It is much faster and easier to implement compared with OAuth 1.0. Tokens no longer need to be encrypted on the endpoints in OAuth 2.0 since they are encrypted in transit.
******************************** END *****************************
