OAuth 2.0 has been derived from OAuth 1.0. The OAuth 2.0 was introduced to remove the complexities involved with encryption of the requests for tokens that were present in OAuth 1.0 and also to make it more scalable. Some of the OAuth 2.0 providers are Facebook, Google, Amazon, Github, Microsoft, Paypal, etc. With the introduction of OAuth 2.0, OAuth 1.0 has become obsolete.
User and their roles in the system :
Here there are four users in the system, as opposed to only three in OAuth 1.0. They are follows :
- Resource server (same as OAuth 1.0) – A website that is capable of storing resources of users.
- Resource owner (same as OAuth 1.0) – An entity who wants to store his resources and can provide access to them to other entities.
- Client (same as OAuth 1.0) – A application or website that wants to access the resources of the resource owner, on his behalf.
- Authorization server – A server that provides temporary intermediate credentials to the client, that are required in the complete process of providing authorization to the client.
How is it different from OAuth 1.0 ?
It is different in the sense that, while in OAuth 1.0 there was only one server, that is the resource server, wherein the end user (resource owner) could store his resources, in OAuth 2.0, there is one extra server in addition to the resource server – the authorization server. The authorization server is responsible for providing temporary credentials to the client that wants to access the protected resources of the resource owner. OAuth 2.0 provides for better organization and separation of responsibilities among the users of the system.
The following diagram that has been taken from RFC 6749 shows the workflow in the case of OAuth 2.0 .
+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+
The steps are explained as follows :
- The client that wants to access the resource owner’s resources, sends an authorization request to the resource owner.
- Authorization is then granted to the client by the resource owner. The authorization can be of different types depending on whether the client contacted the resource owner directly or indirectly.
- The client then uses this authorization grant and requests for an access token after it authenticates with the authorization server.
- After the authorization server authenticates the client and checks if the authorization grant provided by the resource owner is valid, it provides an access token to the client.
- With the access token that it received from the authorization server, the client requests for access to the resources stored in the resource server.
- The resource server checks if the access token is valid or not and accordingly provides access to the token.
The concept of Refresh tokens :
The OAuth 2.0 introduces the concept of providing refresh tokens. Refresh tokens are used as a substitute for access tokens that have been issued by the authorization server to the client, when the access tokens expire. When the client makes an authorization grant to the authorization server for the access token, after authentication by the authorization server, it gets back two tokens – an access token and a refresh token. The refresh token can be used instead of the access token in circumstances where the resource server finds out that the access token has expired. This helps continue the process and avoids the issue of creating a fresh access token.
Under normal circumstances (in the absence of refresh tokens) when the access token expires, the process needs to start all over from the beginning. When the client tries to access the resources by providing the access token (that was issued to it by the authorization server) to the resource server, on checking if the resource server find the access token to have expired, the client needs to begin again with requesting authorization to the resource owner and then follow it up with authentication to the authorization server again, and requesting a new access token.
The following diagram, taken from RFC 6749 explains the workflow in the case of refresh tokens.
+--------+ +-------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | |Authorization| | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +-------------+
Advantages of OAuth 2.0 :
- There is a clear separation of roles and responsibilities among the different components of the system.
- OAuth 2.0 has support for both native and mobile applications.
- It supports various types of use cases depending on whether the client of confidential or public type.
- In OAuth 2.0, the client makes requests for tokens over HTTPS and does not require for the requests to be hashed using HMAC.
Disadvantages of OAuth 2.0 :
- OAuth is not backward compatible.
- Phishing attacks are possible.
- The server gets to know more information about the resources owners and clients.
- Denial of Service attack is possible on clients and servers.
- Replay attack is possible.