In order to use some resources and applications on the Internet, it is necessary for the user to authenticate and authorize. For example, to take an online course, you need to create personal account. Instead of registration and entering personal data, users can simply authorize through social networks.
The OAuth 2.0 standard is designed to implement such scenario. It is created to give third-party applications limited access to protected resources with no risk to user data. The framework simplifies the authentication process.
What is OAuth 2.0?
OAuth 2.0 is an open authorization framework that allows third-party applications limited access to HTTP service resources. OAuth and OpenID have a lot in common, but there is a fundamental difference between them:
OAuth is a means of granting rights to use some resource (e.g., an API of some service).
OpenID is an authentication tool: using it one can make sure that the user is exactly who is supposed to be. The authenticating party determines exactly which rights are granted to the authenticated user.
Resource Owner: the user who has the right to grant access to protected resources.
Resource Server: a server with protected resources and capable of receiving and generating a response to requests for protected resources through the use of an access token.
Client: an application that accesses protected resources on behalf of the owner.
Authorization Server: a server that issues access tokens for client applications after successful authentication and authorization of the resource owner.
The interaction is described on the diagram below:
The client requests the end user to authorize on the authorization server (the user is redirected to the social network login page, and then asks for permission to access from the client application).
After the end user is authorized, the client receives an authorization grant. (In fact, the authorization grant is issued to the client by the authorization server after the end user has authenticated and confirmed the granting of the rights requested by the client).
The client requests an access token from the server. The client provides some identification data about itself and an authorization grant from the user. The access token is an alternative to the login and password, has a limited validity period and is associated with certain rights restrictions.
If the client is verified and the authorization permission is valid, the authorization server creates an access token for the client and transmits it. Authorization is complete.
The client uses the access token to authorize on the authorization server.
The client accesses the necessary resources (reads the user's social network account data and creates his account based on it).
Why is a refresh token necessary?
Imagine a situation that someone gets a hold of your access token and gains access to your secure data. That is why tokens have an expiration date. Access tokens usually have a short expiration time, from a few seconds to a few days, refresh tokens have a longer lifetime.
This means the intruder will have access to the data as long as the access token is not expired. Let's assume that someone has also got the refresh token and used it before you did, thus getting a new access token. In this case, you cannot retrieve data from the provider, but to solve this problem you only need to log out and log in again.
The old tokens will be either invalid or deleted. After this procedure, you get new access/refresh tokens and can continue your work safely.