The oauth protocol is used to increase the security between client and server. It additionally involves authorization of users and token based security. The OAuth 2.0 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.
In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner’s credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:
o Third-party applications are required to store the resource
owner’s credentials for future use, typically a password in
o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
o Third-party applications gain overly broad access to the resource
owner’s protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party’s password.
o Compromise of any third-party application results in compromise of
the end-user’s password and all of the data protected by that
OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.
Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token — a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service authorization server), which issues the printing service delegation-specific credentials (access token).
The following concepts are used in OAuth protocol specification:
• Resource Owner:
Resource owner is an entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an end-user.
A client is an application making protected resource requests on behalf of the
resource owner and with its authorization.
• Authorization Server:
Authorization Server is the server issuing access tokens to the client after
successfully authenticating the resource owner and obtaining authorization.
• Resource Server:
Resource server is the server hosting the protected resources, capable of
accepting and responding to protected resource requests using access tokens.
• Authorization Code:
The authorization code is obtained from an authorization server when the
resource owner grants access to the owner’s resource.
• Access Token:
Access tokens are credentials used to access protected resources.
• Authorization Endpoint:
The authorization endpoint is the endpoint on the authorization server where
the client requests for authorization. The request will be redirected to allow
the resource owner to log in and grant authorization to the client.
• Token Endpoint:
The token request endpoint is the endpoint on the authorization server where
the client application exchanges the authorization code for an access token.
• Redirect Endpoint:
The redirect endpoint is the endpoint in the client application where the
authorization server redirects to after the resource owner grants authorization
to the client application. The client will receive an authorization code which
can be used to exchange for an access token.
The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps:
(A) The client requests authorization from the resource owner. The
authorization request can be made directly to the resource owner
(as shown), or preferably indirectly via the authorization
server as an intermediary.
(B) The client receives an authorization grant, which is a
credential representing the resource owner’s authorization,
expressed using one of four grant types defined in this
specification or using an extension grant type. The
authorization grant type depends on the method used by the
client to request authorization and the types supported by the
(C) The client requests an access token by authenticating with the
authorization server and presenting the authorization grant.
(D) The authorization server authenticates the client and validates
the authorization grant, and if valid, issues an access token.
(E) The client requests the protected resource from the resource
server and authenticates by presenting the access token.
(F) The resource server validates the access token, and if valid,
serves the request.
Reference – oauth.net