[Distributed Project] Authentication Service Center, Social Login OAuth2.0, Single Sign-On, Distributed Session Solution

1. Registration

1.1 Integrate Alibaba Cloud SMS Verification Code

The front-end countdown for verification code resending.

Verification code anti-swipe back-end verification: When a user requests a verification code, the requested IP and mobile phone number are stored in Redis, and the sending frequency is limited, for example, only one request per minute/single IP/single phone number can be made. If the script cannot obtain the real IP of the user, it directly filters such requests. Plus the image verification code, the SMS can only be sent after entering the verification code

1.2 Registration data verification

Validation errors are returned to the front-end registration page. and redirects back to the registration page. (Using the Session principle, put the data in the Session, as long as you jump to the next page to retrieve the data, the data in the session will be deleted) [Since the Session is used here, the distributed Session problem must be solved]

After using the verification code, the verification code must be deleted (token mechanism).

After there is no error, call the user center remote service to register, (username and mobile phone number cannot be occupied).

1.3 User Center User Registration

Using the exception mechanism, the user name and mobile phone number cannot be occupied. If the occupancy is found, the corresponding exception will be thrown.
The password cannot be saved in plain text, MD5 & MD5 salt value encryption (Spring's password encryptor)

2. Login

2.1 Simple account and password login

The database queries the corresponding password through the user name, and then compares the password.
Interview question: What if there are many users and it is very slow to log in and check the database? —> Database indexing

2.2 Social Login OAuth2.0

In order to simplify the login and registration logic of my website, the social login
OAuth2.0 process is introduced:

The specific implementation process takes Weibo login as an example:
first apply for the Weibo website access interface, and get the App Key (ie client_id)

1. The front-end page guides the user to the Weibo login page, and the request address includes the client_id and the callback address for successful login.
2. If the user agrees to the authorization (the user enters the account password of Weibo, logs in and authorizes), the page jumps to the callback address specified before, and attaches a code to the url
3. Through the code code, client_id, client_secret, in exchange for the Access Token (access token), the background is implemented, the code can only be used once
4. With an access token, you can access a given interface.

3. Distributed Session is not synchronized and does not share the problem

Session principle and problems

The session exists in the server's memory. After the server creates the session, it instructs the browser to save the sessionId in the cookie, and the browser will bring the cookie with each visit.

1. Sessions cannot be shared across different domain names, and different services cannot be shared. (Different domain names come with different cookies)
2. The same service, cluster environment, session cannot be shared.

Option 1, Session replication

Session replication, the same service on different hosts, synchronously replicate the session.
Advantages: Tomcat native support, only need to modify the configuration file.
Disadvantages: Session synchronization requires data transmission, takes up a lot of bandwidth, and each service stores a large number of sessions, which is impossible to use in large distributed clusters.

Option 2, client-side storage

Client storage. The advantage is that the server does not need to store the session. The disadvantage is that it is all shortcoming, dangerous, occupies bandwidth, stores limited information, and may be tampered
with. This method will not be used.

Option 3, hash consistency

Let the same ip load balance to the same server, the advantage is that only need to change nginx, no need to modify the application code, support horizontal expansion.
The disadvantage is: the server needs to be logged in again when the server crashes, and the rehash may cause some users to not be routed to the correct session.

Option 4, unified storage

Advantages: No security risks, can be scaled horizontally. The server restarts and flashes will not cause session loss
. Disadvantages: One network call is added, and the method of obtaining the session needs to be modified, and data retrieval from redis is much slower than in memory.

Ultimately choose unified storage.
Unified storage, after logging in, the session is stored in redis, and the scope of the cookie is enlarged, so that the subdomain and the parent domain share the sessionId, and the service uses the sessionId to retrieve the session from Redis

The core principle of SpringSession

Integrate Spring Sessioin
import dependencies - configure selection to use redis - set session expiration time - configure redis access - annotation plus RedisSession
is best to use Json's serialization method
Change the cookie scope and write a configuration file class

SpringSession source code... mainly uses the decorator pattern

4. Single sign-on SSO

4.1 Introduction to Single Sign-On

Single sign-on means that in multiple systems, a user only needs to log in once, and each system can perceive that the user has logged in.
Using SpringSession achieves a system where multiple microservices and subdomains share the purpose of Session.
But if it is multi-system. Different systems of the same company have different domain names. It is also hoped that one system can be logged in, and access to another system can also be in the login state.
For example, when we log in to Weibo, we also log in when we visit Sina.com

4.2 SSO Implementation

Core: Even if the domain names of the three systems are different, find a way to synchronize the tickets of the same user for the three systems

Key Core:

1. Leave login traces to the login server
2. When the login server is redirected, the successful login token is attached to the url address
3. Other systems need to process the key token on the url address, obtain the corresponding user through the token and save it in their own session
4. You can stay logged in if your system has a session.

Five, interview questions,

①If cookies are disabled, how to save the login status?

The session is in the server memory or in redis, and the session can be found through the sessionId to maintain the login state, so the client has to keep this sessionId so that it can be returned to the server when interacting. Cookies can be used so that each interaction is automatically carried over. The core is to bring sessionId when interacting with the server. There are also the following methods:

1. URL rewriting, appending sessionId directly to the URL path. [Not very good, so the URL of the page has to be rewritten, and there can be no static page]
2. Put sessionId in the request header.

Or simply give up the session, use Token (JWT), and each front-end request brings the token, and the server parses the token to prove that the user is legal. The advent of JWT has made single sign-on easier.

② Single sign-on principle? The flow of OAuth2?

see above

③ How do different systems and different domain names perceive your login?

All systems access the same SSO system [disadvantage of SSO pressure]

Thank you for your likes, favorites, and attention. Let's make progress together and continue to create better articles
. Please indicate the address for reprint: https://blog.csdn.net/weixin_44179010/article/details/124264393