Introduction
OAuth 2.0 (Open Authentication) is an authorization framework which enables websites or applications to obtain limited access to a HTTP service (such as Facebook, GitHub, Google, etc…). It is commonly used as a way for users to authorize third-party (websites or application) to access their information on other web services but without sharing their credentials. It is designed specifically to work with HTTP. OAuth 2.0 provides authorization flow for web, desktop and mobile applications. To summarize, OAuth is an authorization protocol, rather than an authentication protocol.
Where is OAuth Required?
The internet world has lots of web services running on it and as a result the need arises for certain web services to access information which is available in other web services. However, each web service has its own user authentication credential making it difficult to do so.
The idea, therefore, is to give user authorization to, for example, web service ‘A’ to access information from web service ‘B’. To elaborate, Google services like Google calendar, allows developers to access information from the calendar when a user provides credentials. There is a standard authorization protocol which is decided by web services developers to access user information with authorization.The OAuth and OAuth 1.0 versions are using cryptography signatures for added security and OAuth 2.0 has dropped cryptography signature by SSL/TLS. Thus, by using OAuth we can get authorization to get user information or perform certain functionalities on user’s behalf from third-party services.
Roles
- Resource owner – He is capable of granting access to protected resources. When it is a person we call it as end-user.
- Resource server – The Server which holds the protected resources. It is capable of accepting and responding to protected resource requests using access tokens.
- Client – An application or website which is making requests for protected resources on behalf of resource owner and its authorization. It has Client Identifier which is publicly exposed string which is used by service API to identify the client application and Client Secret is used to authenticate the identity of the application to the service API when the application requests to access a user’s account, and must be kept private between the application and the API.
- Authorization server – The server issuing an access_token to the client after successfully authenticating the resource owner and obtaining authorization.
Abstract Protocol Flow
- Client requests the resource owner for authorization. The authorization request can be made directly to the resource owner (as shown above) or indirectly via Authorization Server.
- Client receives an authorization grant from resource owner which is a credential representing the resource owner’s authorization.
- The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
- The authorization server validates the client details and resource owner authorizations, if it is valid then it issues an access token to the client.
- Client requests to get protected resource by passing access token to resource server.
- Resource server validates an access token and, if valid, it responds to the request.
In my next blog, we will see how Authorization Grant is used to obtain Authorization.
