Authorization across services through OAuth 2.0

OAuth is an Authorization Protocol that allows third party service to access secured resources, on behalf of resource owner. Authorization is different from Authentication as Authentication is process of verifying who user is, while Authorization is process of verifying what they have access to. Therefore, OAuth is standard for allowing services trying to access each other on behalf of the user.

OAuth provides delegated access. This concept can be explained using Valet Key example. In many hotels, customers can hands their car keys to valet for parking car on their behalf. To prevent theft, some cars come with valet key which has reduced access. In this example, valet service needs access to car service, for which, only required subset of services are provided by the customer, through valet key. This represents delegated access.

Figure: Sign in through Google, Facebook, which uses OAuth to authorize the 3rd Party Service to access user data.

OAuth is thus an open standard for access delegation, which is commonly used as way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.



Elements of OAuth :
To describe elements involved in OAuth, we pick sample scenario in which OAuth may be employed. Consider that customers of an online photo printing service require feature which allows printing service to directly fetch users photos from their Google Photos account. To implement such feature, trivial approach would involve printing service requesting login credentials of user for their Google account. This approach obviously is highly unsafe as users can’t trust printing service with access to their entire Google account. This is where OAuth comes in.

Terminology used to describe participants/elements in an OAuth system are :

  1. Resource –
    It represents data which is to be accessed by 3rd Party service. In our example, Photos of user represent resource.
  2. Resource Owner –
    The resource owner is actual owner of resource. For our scenario, original owner of photos is resource owner.
  3. Client –
    The client represents 3rd Party service which requires access to the Resource on behalf of the Resource Owner. In our example, Photo Printing Service is the Client.
  4. Resource Server –
    It represents server on which Resource is securely stored. In our example, photos are hosted on Google Server, which acts as Resource Server.
  5. Authorization Server (Auth Server) –
    To implement OAuth protocol, an additional server has to be provided by entity which owns Resource Server, i.e., Google, since Google is hosting resource and has burden of security.

Instead of providing functionality of Auth Server on Resource Server itself, separate server is used to alleviate unnecessary overload on Resource Server.

OAuth Process Flow :


The OAuth process proceeds in the following manner :

  1. Resource Owner requests service from Client, in our case, printing photos.
  2. Client contacts AuthServer to request Resource, i.e., Photos on Google’s servers.Auth Server sends prompt to Resource Owner inquiring about request it received from Client in the form of login window from Google.
  3. User confirms that services requested by Client and grants authorization to Auth Server on behalf of Client. This provides delegated access to Client.
  4. Auth Server receives request for authorization from Resource Owner.
  5. On authentication of and confirmation from Resource Owner, Auth Server sends Client an Access Token permitting it to access required resources hosted on Resource Server.
  6. Client provides Access token to Resource Server.
  7. On validation of the Access Token, resource is provided to Client.
  8. Finally, user is able to access services of Client which can access secured resources on behalf of user.

Flow detailed above is referred to as an Implicit Flow. In some OAuth flows, instead of directly providing Client an Access Token, an intermediary Authorization Token may be provided by Auth Server to Client. To access resource, Client needs to first provide the Authorization Token to the Auth Server and make request for an access token. Such an OAuth flow is known as Authorization Code Flow.

Drawback of directly providing Access Token (Implicit Flow) is that access token may be used by unauthorized parties. Authorization Code Flow is more secure as the mechanism of Access Token exchange can be secured using Authorization Token.

The implicit flow is better suited for short-lived access token used with JavaScript applications.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.


Article Tags :
Practice Tags :


Be the First to upvote.


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.