Access OAuth2

OAuth 2.0 is an authorization protocol whose core is obtaining and using access tokens.
The authorization code licensing process requires the introduction of authorization codes to ensure security and achieve user experience.
OAuth 2.0 can also be regarded as a delegation protocol, in which users entrust third-party software representatives to operate.
The authorization code permission process is the most complete and secure authorization method in OAuth 2.0.
Improper use may cause safety issues, and various regulatory details need to be followed.
HTTPS needs to be used to ensure communication security.
JWT is not part of OAuth 2.0, but an extension of it.
OAuth 2.0 provides the framework on which OIDC implements identity authentication.
Both third-party software and platform parties need to improve their security awareness to ensure the security of OAuth 2.0.
OAuth 2.0 is an effective tool to solve authorization and authentication problems.

The key points of using OAuth 2.0 for mobile apps are summarized as follows:

Mobile Apps can be divided into two types: serverless and server-side, the latter using OAuth 2.0 is more secure.
Serverless apps can use the PKCE protocol to prevent authorization code leakage, but sensitive information such as app_secret is not recommended.
There is a server-side App that can obtain access tokens through the server, which is similar to the web application process and has high security.
WeChat and other platforms recommend that mobile apps use background services to obtain access tokens.
When using a third-party login such as WeChat login, the App obtains the authorization code, and the server uses code and app_secret to obtain the access token.
It is not recommended to save sensitive information on the App side. Using the server side can avoid security issues.
The PKCE protocol can ensure the security of serverless apps to a certain extent.
It is recommended that mobile apps use server and background communication to obtain access tokens whenever possible.
The core ideas of OAuth 2.0 can be applied to Apps to ensure data security through safe use.

The security risks and preventive measures of OAuth 2.0 can be summarized as follows:

CSRF attacks can be prevented through the state parameter state.
XSS attacks require escaping the response content to prevent the injection of malicious code.
Horizontal override requires verification of data ownership to avoid data confusion among different users.
If the authorization code is stolen, you need to verify the app_id and invalidate the used authorization code immediately.
Redirect URI tampering requires integrity verification of the URI.
It is necessary to comply with various specifications and details of OAuth 2.0 to ensure security.
Lack of security awareness among developers is a common cause of these vulnerabilities.
Thinking from the attacker's side can also help uncover additional risk factors.
OAuth 2.0 also faces common security risks across the Internet.
Security precautions need to comprehensively consider various possible attack scenarios.

Implementing OIDC using OAuth 2.0 can summarize the following points:

OIDC is an open user identity authentication standard protocol built on OAuth 2.0.
OIDC has added an ID token, which is used to transfer user identification information, and third-party software can use it to record user login status.
OIDC has also added a new UserInfo endpoint for third-party software to obtain more user information.
The ID token is a token in JWT format, containing necessary statement information such as iss, sub, aud, exp, etc.
The third-party software only needs to parse the payload part of the ID token to obtain user identification and other information.
Single sign-on is an application scenario of the OIDC protocol.
OAuth 2.0 provides a basic authorization framework on which OIDC implements identity authentication.
When implementing OIDC, you need to pay attention to the security of ID tokens, obtaining UserInfo information, etc.
OIDC provides a standard identity authentication solution.

Key points for implementing OAuth 2.0 using Spring Security:

The authorization server uses JdbcAuthorizationCodeServices to store authorization codes and JwtTokenStore to store JWT tokens.
The resource server verifies the JWT token through the local public key and verifies permissions.
Supports three modes: resource owner credential permission, client credential permission, and authorization code permission.
TokenEnhancer can be added to add additional information to the JWT token.
Single sign-on is achieved through authorization code permission, and OAuth2RestTemplate calls the resource server.
The client needs to configure client information, token endpoint, authorization endpoint, redirect URI, etc.
Security configuration requires opening access rights to the login page and authorization page.
Be careful to use HTTPS to transmit tokens to avoid security risks such as CSRF attacks.
Spring Security OAuth 2.0 is simple to use, but requires understanding the workflow.

Key points of the microservices reference architecture using OAuth 2.0/JWT:

Microservices can be divided into 5 layers: traffic entry layer, Web application layer, gateway layer, BFF layer and domain service layer.
The gateway layer is responsible for key security functions: verification and conversion of OAuth access tokens, and Scope-based authentication.
Typical application scenarios include: first-party web applications, first-party mobile applications, and third-party web applications.
The IDP service is responsible for OAuth protocol processing, token management, and user authentication.
The front-end authenticates via OAuth access tokens, and the back-end authenticates via JWT tokens containing user information.
The gateway converts between the two tokens to enable mixed use.
Different from traditional web applications, microservices emphasize service autonomy, elastic scaling, and statelessness.
Microservice security strives for zero authentication, fine-grained authentication, and stateless sessions.
Understanding the microservice security mechanism will help you deploy and operate OAuth 2.0.

The overall structure of the open platform system:
- Third-party software: Application software implemented by third-party developers or ISVs by connecting to open platforms.
- Open platform: includes API gateway service, OAuth 2.0 authorization service and third-party software developer center service.
- Protected resource services: API services provided by the open platform require OAuth 2.0 authorization before they can be accessed.
Authorization procedures for major open platforms:
- It is recommended to use the authorization code licensing process.
- The authorization flow charts of open platforms such as WeChat, Alipay, and Meituan all have text related to the authorization code.
Parameter description in the authorization code process:
- Parameters used in the redirection process: response_type, client_id, redirect_uri.
- The authorization endpoint responds to the parameters used by Xiaotu software: code, state.
- The basic parameters that need to be passed when applying for an access token: grant_type, client_id, client_secret, code.
- The token endpoint responds to the parameters involved in Xiaotu software: access_token, token_type, expires_in, refresh_token, scope.