Several schemes of single sign-on

Video explanation link

The reason for single sign-on

When distributed microservices become mainstream, it is necessary to solve the problem of only storing sessions in a single user module, and other modules need to be able to obtain user information in the same way to avoid repeated logins by users.

Option One

Nginx proxy, hash the IP, the session generated by the IP is stored in a certain server

Solution questions:

1. Single point of failure: When a server is down, all sessions stored on the server are lost, which violates high availability.
2. All servers have full modules, which cannot meet the needs of microservice splitting

Option 2: session synchronization

problem:

1. Each microservice needs to be synchronized, the same session is stored too much, and the information is redundant
2. Lag problem: If the module function is called before the synchronization is completed, there will be problems.
   Advantages: The configuration is simple, and Tomcat can be modified; it basically meets the needs of microservices.

Solution 3: third-party storage device to store session

[Reference link](https://blog.csdn.net/wzljiayou/article/details/109550565?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522161594369116780255299779%2522%252C%2522scm%2522%253A%252220140713.130102334. pc%255Fall.%2522%257D&request_id=161594369116780255299779&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2 _all first_rank_v2~rank_v29-12-10955
0565.first_rank_v2_pc_rank_v29&utm_term=95%E7%8D %99%BB%E5%BD%95)

Single sign-on within multiple modules of a system can be realized.

difficulty:

1. The generation of uniqueness sign key.
   Cannot use UUID: Can the UUID generated by system A be adopted and used by system B? How to ensure that the UUIDs of all systems are unique?
   UUID as sessionID is risky: sessions of different systems are inconsistent, and duplicate IDs may be generated.
2. How to determine whether a session has been generated

Solution:
1. Write back to the client, and then carry the key when the client initiates a request, indicating that the user login information already exists in the third-party storage.
Where to write: You can write to cookie or sessionStore.
2. The method of generating unique ID: snowflake algorithm, etc.

Solution 4: Single sign-on for docking with third-party systems

The core problem solved by Oauth2.0: avoid the system (such as Baidu Netdisk) from getting the account password of your third-party system (such as QQ).

An example of the second step:

The third step: The clientID needs to be carried to indicate which system requested the third-party system to log in.
Status code: which authentication method. callback: callback function: to prevent other systems from imitating Baidu SkyDrive to obtain permissions, so a callback function is needed so that even if other services call this URL, the callback will be sent to the Baidu SkyDrive server

The fourth step: QQ only serves as the operation of the verification platform, and there is no need to store the session information for logging in to the Baidu network disk.
The content of the response back needs to meet: 1. Encryption. 2. Information needs to be stored (because QQ does not store it, but a unique mark must be given) 3. Expiration time
This leads to JWT, which also fixes the encryption requirements, unique mark and expiration time.

Introduction to JWT
Core: Asymmetric encryption
Three parts:
Header: Mainly set some specification information, and the encoding format of the signature part is declared in the header.
Payload: The part of the token that stores valid information, such as user name, user role, expiration time, etc., but don't put the password, it will be leaked!
Signature: After the header and the payload are respectively encoded in base64, they are connected with ".", then salt is added, and finally the encoding type declared by the header is used for encoding, and the signature is obtained.
Basic principle: Generate two keys at the same time: a private key and a public key, the private key is kept secretly, and the public key can be issued to a trusted client

Encryption and decryption are performed on the QQ side, and Baidu Netdisk only obtains the token

Step 5: Get the token to access the QQ server, QQ receives the token and decrypts it.

Extension:
Cookie-based single sign-on
encrypts the user name and password and stores it in a cookie. After that, when visiting the website, the user's permission is verified in the filter. In a sense, the user feels that he has logged in only once.

The disadvantage of this method is that the user name and password are transmitted multiple times, which increases the risk of theft, and cannot cross domains. Compared with the session, the cookie is less secure, and it cannot handle the cookie disable scenario.