In 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 the restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:
- Third party applications are required to store the resource owner’s credentials for future use.
- Servers are required to support password authentication, despite the security weakness inherent in password.
- Third-party applications gain overly broad access to the resource owner’s protected resources, without any ability to restrict duration or access to a limited subset of resources.
- Resource owner cannot revoke access to an individual third party without revoking access to all third parties.
- Any compromise of third party application results in compromise of the end user’s password and all of the data protected by that password.
How OAuth addresses these issues:
OAuth addresses these issues by introducing an authorization layer and separating the role of client from that of the resource owner. In OAuth client requests access to the resource 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 credentials to access protected resource, the client obtains an access token. Access token is a String that denotes a defined scope, lifetime and other access attributes. Access tokens are issues by Authorization server with the approval of resource owner. Then client uses this access token to access the protected resource hosted by the resource server.
OAuth defines four roles:
- Resource Owner :- 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.
- Resource Server :- The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
- Client :- An application making protected resource requests on behalf of the resource owner and with its authorization.
- Authorization Server :- The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Following are the steps that describes the interaction between four roles:
- The client requests authorization request from the resource owner. The authorization request can be made directly to the resource owner or via the authorization server as an intermediary.
- 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 extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
- The client request an access token by authenticating with the authorization server and presenting the authorization grant.
- The authorization server authenticates the client and validates the authorization grant and if valid provides an access token.
- The client requests the protected resource from the resource server using access token.
- The resource server validates the access token and serves the request is token is valid.
Blog on Authorization Grant can be found here.
Abstract for The OAuth 2.0 Authorization Framework can be found here.