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 :
- Resource –
It represents data which is to be accessed by 3rd Party service. In our example, Photos of user represent resource.
- Resource Owner –
The resource owner is actual owner of resource. For our scenario, original owner of photos is resource owner.
- 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.
- 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.
- 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 :
- Resource Owner requests service from Client, in our case, printing photos.
- 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.
- User confirms that services requested by Client and grants authorization to Auth Server on behalf of Client. This provides delegated access to Client.
- Auth Server receives request for authorization from Resource Owner.
- 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.
- Client provides Access token to Resource Server.
- On validation of the Access Token, resource is provided to Client.
- 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.