Let’s review single-system logins

When I was learning JavaWeb, login and registration was one of the most common features I worked on (as a Servlet beginner, as a SpringMVC student, as a project follower…). I can’t even count how many times I’ve logged in and registered anyway… Here is a brief description of how to do the login function when we first learn.

Login: Saves user information in the Session object

If you can query it in the Session object, you have logged in

If it is not found in the Session object, it is not logged in (or logged out).

Logout (Logout) : Deletes user information from the Session

Remember me (close the browser, open it again and stay logged in) : use it in conjunction with cookies

Single server mode

Session-based authentication

The client (browser) accesses the server through session-based authentication.

After the client successfully logs in to the server for the first time (authentication is successful), the server saves the user information in the session container and generates a session_ID in the cookie of the client. Session_id corresponds to the user information in the server session container.

When the client accesses the server next time, the cookie with session_id can verify whether the user information exists on the server, so as to determine whether to perform login authentication.

Session_id becomes invalid when the user logs out or the session expires

  • The characteristics of
    • The server consumes resources to store session information
    • Session_id must be stored in client cookies

Multi-server mode

In the multi-server mode (distributed system), if session authentication is used, the client needs login authentication to access service A and service B of another module, which results in poor user experience

(For example: after the successful login of Douban movie, access to douban music, douban reading, etc., also need to log in, the user experience will be poor)

The solution at this point is single sign-on

We can separate out the login function and make it into a subsystem, as shown below:

When you do single sign-on, what is single sign-on

Single sign on SSO

In multiple servers in the same system, users only need to log in once to access all servers under the system

Compared with single-system login, sso requires an independent authentication center. Only the authentication center can accept security information such as user names and passwords. Other systems do not provide login portals and only accept indirect authorization from the authentication center. Indirect authorized by token, sso authentication center to verify the user’s user name password no problem, create the authorization token, in the process of the next jump, authorization token as parameters sent to each subsystem, subsystem get tokens, quick to authorize, to create a local session, local session login method with single system login the same way. That’s how single sign-on works.

There are three common sso methods:

  1. Session broadcast mechanism: Replication by session

  2. cookie + redis

    (1) Redis: generate unique random values (IP, user Id, etc.) in key, and store data in value.

    (2) Cookie: put the key value generated in Redis into the cookie

    Access other modules in the project, send a request to send with the cookie, obtain the cookie value, do things with the cookie, and then query the key value obtained by the cookie in Redis. Query according to the key, and log in when the data description can be found.

  3. JWT: The token is generated as a string containing user information according to certain rules. What are the rules

Session Broadcast mechanism

Session authentication is still used. After service A logs in successfully, the client copies the session to another server

  • The characteristics of
    • There are many servers, and replicating sessions consumes resources
cookie + redis

After the client successfully logs in to the server, the user information is stored in redis ==key: unique user representation (such as ID) value: user information ==, and the redis key is placed in the cookie of the client

When the client accesses other services, it first gets the key in the cookie and queries in Redis. If the key is found, it indicates that the client has logged in

token

After a client successfully logs in to the server, a token is generated based on the user information. The token can be stored in the cookie of the client or returned in the address bar

When a client accesses other services, it only needs to carry a token. After the authentication succeeds, the server obtains user information

  • The characteristics of
    • The server does not need to save token information
    • There is no limit on how a client can store tokens

conclusion

Single sign-on (SSO) is a technology that makes it easy for users to access multiple systems. Users only need to register once when they log in, and can move freely between multiple systems without having to re-enter their user name and password to confirm their identity. It can also be interpreted as sharing a login interface. That is to say, as long as the user information is saved to Cookie in this login interface, other sub-sites will access this jump to login, and if the Cookie already exists, the sub-site can be authorized to login successfully.

Add the Token field User Name +IP Address + Random Value to the user table UserInfo for login security.

1. Access station A and go to the public login page.

2. After A successful login, write the Cookie login information to the terminal, set cookie. Domain = “terminal domainname.com”, set the Token ticket field in the user table, return to terminal A, and transfer the Token value through the URL.

3. Station A obtains the Token and verifies whether the Token IP address is correct and exists in the data. If the login succeeds, set the Session login information. And reset the Token field (to invalidate the Url)

4. When the user accesses site B, the public login page is displayed.

5. Check whether the Cookie exists. If the Cookie exists, station B is directly returned and the Token value is transmitted through the URL. Site B authentication Token Authenticates the login.

6. Logout: Site B starts to log out, logs out the Session of site B, and requests the public login page to clear cookies. That’s it. If you want to cancel other stations’ sessions, send a request to each of the other stations to cancel.