What is OAuth2 ?

OAuth2 is an authorization framework that allows applications — such as Google, Facebook, and GitHub — to gain limited access to user accounts over an HTTP service. It works by delegating user authentication to the service that hosts a user account and authorizing third-party applications to access that user account. OAuth2 provides authorization flows for web and desktop applications as well as mobile devices.

You must have already used a button that says “Log in with your google account” when you were using some other application to avoid having to do all the registration by hand. In this case you are giving permission to this third-party application to use the resources of your application, in the example cited by Google, these applications have limited access to your information through the HTTP protocol.

Roles

• Resource Owner: Person or entity that allows access to your data.
• Client: It is the application that interacts with the Resource Owner, such as the browser, speaking in the case of a web application.
• Resource Serve: The API that is exposed on the internet and needs data protection. To gain access to information, a token is required, which is issued by the authorization server.
• Authorization Server: Responsible for authenticating the user and issuing access tokens, it is the one who has the resource owner information (the user), authenticates and interacts with the user after the client is identified.

How works ?

In the image above we can see how the authorization flow usually works:

1. Authorization Request: In this part, the client (application) requests authorization to access the user's server resources.
2. Authorization Grant: If the user authorizes the application, he receives an authorization grant.
3. Authorization Granting: The client requests an access token from the authorization server (API) by authenticating its own identity and granting authorization.
4. Access token: If the application's identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the application. The client will already have an access token to manage and the authorization at this stage is already complete.
5. Access Token:  When the client needs to request a resource from the resource server, just present the access token.
6. Protected resource: The resource server provides the resource to the client if its access token is valid.

The authorization server is responsible for SSO (Single Sign On), which centralizes user access credentials and authenticates, manages user permissions and issues access tokens.

The client (application that runs on the user's machine) is defined through two types of application:

• Confidential: clients who are able to maintain the confidentiality of their credentials.
• Public : who are unable to maintain the confidentiality of their credentials

Continuing with the authorization flows, there are 4 ways to work with this integration:

• Implicit - is a simplified authorization flow, optimized for web clients. When issuing an access token, the authorization server does not authenticate the client. It is widely used in SPAs and MVC applications.
• Authorization Code - is achieved by using an authorization server as an intermediary between the client and the user. The client redirects the user to an authorization server. This type of client is used in third-party applications, that is, untrusted.
• Resource Owner Password Credentials - used when the customer requests the username and password directly, which is already used in so-called trusted applications, such as the company's own applications.
• Client Credentials - can be used when the client application is protected, which are used in system integrations.