OAuth2 basics

What is OAuth 2

OAuth 2.0 is an authorization protocol whose core is authorization permission and token mechanism.
It allows third parties to access the user's data on behalf of the user by issuing access tokens to third parties, rather than directly giving the third party a username and password.
It is mainly used to protect the Web API interface. Third parties can only access the API after obtaining authorization and access tokens.
It enables third-party software to securely access data on behalf of users without increasing security risks.
The typical authorization process includes: user login, user authorization, issuance of authorization code, third party exchanging authorization code for access token, and third party using access token to obtain data.
OAuth 2.0 is used in many scenarios, such as logging in to other apps with WeChat, using WeChat applets, etc.
Authorization code permission is the most complete and secure authorization method in OAuth 2.0.
The core idea of OAuth 2.0 can be applied to different scenarios, ensuring communication security while improving user experience.

Requirements for authorization codes

In OAuth2.0, access tokens need to be highly confidential and cannot be directly exposed in the browser. If you do not use an authorization code, you can only communicate through the backend when obtaining the access token, and you cannot establish a "connection" between the user and the client.
Using the authorization code can achieve two redirections, which not only ensures security but also improves user experience. The first redirection is used to obtain the authorization code, and the second redirection is used to re-establish the connection between the user and the client.
As a temporary credential, the authorization code can be exposed on the front end, while the access token can only be transferred on the back end. This not only meets the requirements of communication security, but also achieves a smooth user experience.
The authorization code realizes the combination of indirect communication to obtain the authorization code and direct communication to obtain the access token, perfectly organizing the interaction of the four roles of OAuth2.0.
The idea of authorization code permission can be transplanted to other scenarios. For example, a similar process is used in WeChat mini programs.
Generally speaking, the authorization code mechanism makes the authorization code permission type the most complete and secure authorization process in OAuth2.0.

work process

The workflow of the authorization service can be summarized as follows:

The authorization service is responsible for issuing access tokens and is the core of OAuth 2.0.
Its work can be divided into two parts: issuing authorization codes and issuing access tokens.
Issuing an authorization code requires preparation work, including verifying basic information, verifying permission scope, and generating an authorization page.
After the user is authorized, continue to verify the permission scope, generate and bind the authorization code, and redirect the callback address.
Issuing an access token requires verifying third-party software information, verifying authorization codes, generating access tokens, and binding information.
At the same time, a refresh token is generated, which is used to reacquire the access token after it expires.
Using a refresh token requires verifying information and regenerating the access token.
The scope of permissions needs to be verified throughout the entire process to ensure the principle of least authorization.
The authorization service takes away the complexity and makes it easier for third-party software to access OAuth 2.0.

JWT token

Regarding JWT tokens, the following key points can be summarized:

JWT is a structured token format, including HEADER, PAYLOAD, and SIGNATURE.
HEADER represents header information, PAYLOAD represents the data body, and SIGNATURE is the signature.
JWT can contain user authorization information in the token without requiring a database or RPC query.
Using JWT can implement token internal inspection, and protected resources can directly parse JWT.
The advantages of JWT are computing instead of storage, forcing encryption, and enhancing system availability.
The disadvantage of JWT is that the token status cannot be modified during use and requires supporting key management.
Tokens have three life cycles: natural expiration, use of refresh tokens, and active revocation.
To third-party software, the token remains opaque and core services need to pay attention to the token.
JWT is suitable for scenarios where information needs to be transmitted securely without relying on state.

How to securely and quickly access OAuth 2

Regarding third-party software and protected resource services accessing OAuth 2.0, the following points can be summarized:

Third-party software needs to pay attention to registration information, boot authorization, use access tokens, and use refresh tokens.
When booting authorization, the user needs to be redirected to the authorization service for authorization.
When using access tokens, it is recommended to submit them as form parameters rather than URI query parameters or request header fields.
When using refresh tokens, you need to pay attention to the validity period of the access token to avoid frequent reauthorization.
Protected resource services need to verify access tokens and pay attention to permission scope. Commonly used permissions include different permissions corresponding to different operations, data, and users.
You can use API gateway to handle permission verification uniformly to avoid duplicating this logic for each resource service.
Third-party software cares about obtaining and using tokens, and resource services care about verifying tokens and permission control.
Both of them only need to focus on their own responsibilities and do not have to deal with all the complex processes of OAuth 2.0.

OAuth3 authorization types

OAuth 2.0 defines 4 authorization types:

Authorization Code Grant

Obtain the access token through the authorization code temporary credential, which has the most complete process and the highest security.

Implicit Grant

The access token is returned directly in the front-end communication, no authorization code is required. Suitable for pure front-end applications.

Resource Owner Password Credentials Grant

Get access token directly using username and password. Suitable for highly trusted official software.

Client Credentials Grant

The client obtains the access token directly through app_id and app_secret without user participation. Suitable for accessing public data.

The main difference between these 4 authorization types is the way to obtain the access token. When selecting an authorization type, you need to weigh it based on the application scenario and security requirements, and give priority to authorization code permission types with higher security.

Regarding the four authorization types of OAuth2.0, the following key points can be summarized:

The authorization code permission type is the authorization method with the most complete process and the highest security.
Resource owner credential licensing is available for official software, use username and password to obtain tokens.
Client credential permissions are used to get public data, using app_id and app_secret to get the token.
Implicit permission is suitable for pure browser-side applications and returns the access token directly on the front end.
When selecting an authorization type, give priority to the authorization code license, and then select the most suitable type based on the actual scenario.
The way to obtain the access token is the biggest difference between the four authorization types.
All types are designed to solve authorization problems in actual scenarios and need to be selected based on specific circumstances.
In non-browser environments, consider client credential permissions or resource owner credential permissions.
According to the principle of security priority, choose the most suitable authorization type.