Oauth2 and SSO login difficulties

Nowadays, most websites and applications support third-party login or single sign-on, and it has been a long time since I encountered a system that required entering an account and password. About a year ago, while maintaining the team's support system, I came into contact with the source code of Spring Boot for the first time to implement Feishu third-party login. Facing the complex Spring Security configuration, I had to look around for the direction of the process, and at the same time learn the principles of OAuth 2.0 through major websites. In order to have a deeper understanding of this currently widely used login scheme, I feel it is necessary to make a summary note to avoid being confused about it in the future.

SSO

SSO means single sign-on. When logging into various systems of the same company, you can access all websites with just one login, avoiding the need to enter your account and password multiple times.

Single sign-on

There are many ways to implement SSO. The most common one is to set up an independent authentication server. A concise flow chart can help us understand the principle of SSO based on the authentication center:

1. User accesses system 1

2. System 1 redirects to SSO server

3. User authenticates on the SSO server

4. The SSO server generates a token and redirects it back to system 1

5. System 1 verifies the token and allows access

6. User access system 2

7. System 2 checks SSO token without logging in again

From this process, we can see that the core of SSO is to manage user identity information through a certification center server. When a user logs in for the first time, the authentication server generates a token and distributes it to other application systems. In this way, users do not need to enter credentials again when accessing other systems, which greatly improves user experience and security.

Single logout

Single sign-out (Single Sign-Out) is an integral part of the single sign-on system. It ensures that when a user logs out from one app, all associated apps are also logged out. The main challenge in implementing single logout is how to effectively synchronize the logout status among all participating applications. Typically, this is accomplished by a central authentication server sending logout requests to all logged-in applications.

Kick people offline

Kicking someone offline is an important function in a single sign-on system. It is usually used by administrators to forcefully terminate a user's session.

Although the system maintained before did not have this requirement, it is still a very interesting problem to kick people offline based on JWT. In a session-based user login scenario, you only need to delete the user's session in redis to force the user to be unable to access the system. In the JWT login scenario, the backend can only parse the user information and expiration time from the JWT, and the backend itself has not stored the JWT of all users, so it cannot kick people offline.

In real-life scenarios, we will use two not-so-good methods:

1. Storage JWT in database and Redis: If you need to invalidate a JWT, just delete the JWT directly from Redis.

2. Blacklist mechanism: Redis maintains a blacklist. If you want to invalidate a certain JWT, just add the JWT to the blacklist.

Since JWT is stored in the backend, it directly loses its advantages compared to session, so it is not very good, but there seems to be no better solution.

Summary: One of the very important advantages of JWT is that it is stateless, but in fact, if we want to use JWT reasonably for authentication and login in actual projects, we still need to save JWT information.

Permission update

Although I did not complete the upgrade when upgrading the support system permission authentication to RBAC mode, if I continue to implement it, I will indeed encounter the problem that the permissions cannot be updated immediately :).

Simply put, when the system modifies the user's permissions on the backend, the JWT-based login solution cannot directly update the permissions immediately, and usually needs to wait until the validity period has expired. This situation is essentially the same as kicking someone offline, both are caused by the stateless attributes of JWT. If you want to achieve instant updates, you can never avoid the server controlling user information, that is, storing user permission information in Redis. Every time a user requests, the user's permission information will be queried in Redis in real time.

Summary: JWT is not omnipotent. In order to achieve real-time updates, the client cannot avoid storing user information, but this Cookie + distributed Session can also be implemented. At this time, the advantage of JWT may only be the mobile terminal.

##OAuth2

WeChat authorized login/Feishu authorized login/QQ authorized login/Google authorized login are specific OAuth2 login implementations, which can help users log in to the system without entering account and password, improving user experience.

The implementation of OAuth2 involves four roles:

1. Resource Owner: usually refers to the user;

2. Authorization Server: Usually refers to WeChat Open Platform/Feishu Open Platform, etc.;

3. Client: usually refers to the front end;

4. Resource Server: Usually the application/backend that users want to access;

The user (resource owner) authorizes the client to access its resources. The authorization server issues an access token to the client. The client uses this token to access resources on the resource server.

The general OAuth2 login process is as shown in the figure:

The process of the support system in the group is similar:

1. Enter the support system and find that you are not logged in. Jump to the Feishu authorization page.

2. Scan the QR code on Feishu with your mobile phone to confirm. At this time, the Feishu authorization page will return an authorization code and jump to the support system in the meeting group.

3. The support system in the group uses the obtained authorization code and its reserved appid and appsecret to request Feishu platform in exchange for access_token

4. The support system in the group uses the access_token to go to Feishu platform in exchange for user information (mobile phone number, openId, etc.)

5. The support system in the group returns its own token to the front end

Here is a little security test: Why does OAuth2 not directly return the token to the client, but instead returns an authorization code code to the server?

1. If the client directly obtains the access_token, then the hacker may obtain the access_token through the client and send a request to the WeChat Open Platform/Feishu Open Platform to obtain the user's information, such as the source code of the front-end page and the decompilation of the app.

2. When registering for third-party login, the third-party platform will generate appid and appsecret. These two pieces of information cannot be placed on the client/front-end, but can only be placed on the server to ensure security.