1. Introduction
OAuth2 has become very popular, so what is OAuth2, how to apply it and whether you have applied OAuth2 correctly. In this article, I will share with everyone about OAuth2, how and when to apply grant types. Surely you have also had a need: a user on your system wants to share their information and resources with a 3rd party. The problem is how to authenticate to ensure such sharing. standards of safety and limits the risk of personal information theft of users. Let’s take a look at the validation process of many currently applied websites as follows:
- User uses username / password to log into the system.
- Information authentication system. If valid, a session will be written to cookies.
- As long as the session is active, the user can still connect to the system, grabbing their resources.
With such a process, it is very difficult to meet the above needs while ensuring a 3rd party cannot get sensitive user information such as passwords. If the system applies OAuth2, the above need will be easily solved.
We can define OAuth2 in a simple way as follows. OAuth2 is an authentication method, it needs to be deployed on both the Server and Client sides.
OAuth2 has four grant types:
- Resource Owner Password Credentials
- Authorization Code
- Implicit
- Client Credentials
2. Resource Owner Password Credentials
When is this grant used? The answer is that it should only be used for applications that are truly trusted as it directly processes the user’s login credentials.
The process includes the following steps:
- Application comes up with a form that allows the user to enter login information (eg username / password).
- Application sends its login information and identification information to an authorization server. The Authorizaion server validates the information, returns the access token and refreshes the token (if any).
- The application uses the access token to access resources on the resource server.
3. Authorization Code
When is this grant used? Use for applications with low reliability (3rd party applications requiring access to your system).
The process includes the following steps:
- Application sends a link to an authorization server for the user to initiate the authorization_code process. This link contains information that allows the authorization server to identify and respond to the application.
- User enter login information.
- Login information is sent to the authorization server.
- The authorization server authenticates the credentials of the login and redirects the user to the app’s redirect_uri along with an authorization_code.
- Application requests to an authorization server with authorization_code to receive access token with refresh token (if any).
- The application uses the access token to access resources on the resource server.
3. Implicit and Client Credentials
When is this grant used?
This method is often used in mobile applications or web applications, where confidential information of the client cannot be stored securely.
The flow of this grant is very similar to the Authorization Code except for the part related to authorization_code. Due to security concerns, in this flow, the application will not receive an authorization_code from the Authorization server, instead, the Authorization server will pay the access token directly to the application. This grant type does not support refresh_token.
4. JWT (JSON Web Tokens)
You can see that even though the access tokens are referenced in OAuth 2.0, so far very little information is available on how to create and use them. The truth is that the OAuth 2.0 framework does not specify the format of the access token and the refresh token should use, and developers themselves format and integrate the tokens into their authorization flows. Theoretically, you could use a string, which never expires as the access token, although obviously that’s not secure. However, in practice, many developers have chosen to use the JWT (JSON Web Token) format. JWTs are independent, allowing servers to validate tokens without having to ask for a data source.
A JWT consists of 3 parts:
- Header: Describes the token type and algorithm used for encryption.
- Payload: contains data.
- Signature: to verify token.
All three parts must be Base64URL encoded in order for them to be transferred securely in the query string. You can use many hashing algorithms with JWT and payload has many predefined fields (also known as registered claim names). This article uses the RS256 (RSA Signature with SHA-256) algorithm and specifies two registered claims in the payload: exp (when tokens expire), and iss (Issuer). In addition to the supported claims, you can define payload claims such as token scopes.
Every time JWT reaches the server, the system will first analyze the JWT and verify if the algorithm specified in the header is supported or not; It then checks the Signature to make sure that the JWT is valid and finally, validates that the registered claims (if they exist) are valid. In the case of this tutorial it means making sure that the JWT has not expired (exp) and is coming from a anticipated source (iss). Custom claims, such as scopes, can be extracted from tokens and manually validated.
5. Expiration Date and Refresh Token
In addition, developers need to control the lifespan of the access token and usage of the token refresh. In general, if you are building an authorization server to protect important resources, it is better to avoid using refresh tokens and keep the access token in the short term. For less important resources, you can use the refresh token and let the access token last a little longer. Avoid creating long-term access tokens for easier development.