Introduction to the

Single sign-on (SSO) In multiple application systems, users only need to log in once to access other trusted application systems

Technical background

Multi-system login authentication mechanism:

  1. Users access applications that need to be logged in to.
  2. The application checks the session information list. If the user is logged in, the login page is displayed.
  3. The user enters the login information to complete the login authentication.
  4. The server generates the unique sessionId stored in the server set expiration time, and returns the login credential Token, stored in the browser local Cookie;
  5. When the user accesses the application next time, the request will carry the Cookie, and the server will find the corresponding session according to the Cookie, and judge whether the user logs in according to the session. If no special configuration is made, the Cookie is named jsessionID and the value is unique on the server.
  6. The user logs out and the SessionId is deleted on the server.

The above is the basic implementation principle of JWT (JsonWebToken)

Single sign-on under the same domain name

In general, enterprises only have one level-1 domain name, such as Baidu.com. They distinguish different applications through the level-2 domain name, such as Baidu map.baidu.com and Baidu web disk pan.baidu.com. At the same time, they also have a login system, such as sign.baidu.com, which only contains the login function.

  1. When a user accesses an application to be logged in to, such as Pan.baidu.com, the server switches to the application
  2. The user enters the login information to complete the login authentication.
  3. The server generates the SessionId and returns the login certificate Token. The login platform writes the Token into the Cookie and changes the domain of the Cookie to the top domain, namely baidu.com. So that all secondary domain names can access the top domain Cookie;
  4. After a successful login, the user is redirected to the platform that the user wants to access, such as Pan.baidu.com. The browser automatically carries the Cookie information, and the server detects the user login information and authenticates the login status

Ps: Session information cannot be shared between different domain name services. The server can use the Spring-Session technology to solve this problem

Single sign-on under different domain names

Single sign-on under the same domain name is not a single sign-on in the real sense, and cookies shared by all secondary domain names have security risks. The following describes how to implement single sign-on (SSO) under different domain names under the Central Authentication Service (CAS). As the name implies, the CAS is an independent user authentication system, including the CAS Client and CAS Server.

First, throw out a CAS workflow flow chartSSO workflow:

  1. Users can access resources that require authentication, for example, a.com.
  2. The a.com service found that the user did not log in, and 302 was redirected to the CAS Client.
  3. A user enters login information and sends a request to the CAS Server. The CAS Server verifies the login information. After the verification succeeds, the CAS Server generates a JeSessionId and stores the JeSessionId in a browser Cookie. Generate a Service Ticket (ST Ticket) as a parameter to redirect to a.com.
  4. After a.com gets the ST ticket, it sends a request to CAS Server to verify the validity of the ST ticket. After the verification is successful, the login status of A.COM is written into the session and the cookies under the A.COM domain are set.
  5. Users can visit a.com again with the Cookie stored in the a.com login information (JeSessionId) login verification;

When users access other trusted applications b.com:

  1. When a user accesses b.com, the B.com service detects that the user does not log in, and 302 is redirected to the CAS Server.
  2. If you have logged in to the CAS Server, the browser automatically carries a Cookie containing the login information. You do not need to log in to the CAS Server again.
  3. CAS Server generates ST tickets and redirects them to B.com.
  4. The B.com sends a request to the CAS Server to verify the validity of the ST ticket. After the authentication succeeds, the B.com login status is written into the session and cookies in the B.com domain are set.

In this way, B.com does not need to go through the login process, and since then, “one login, everywhere access” has been realized.

Ps: business system to the CAS Server authentication ST the necessity, the effectiveness of the instrument, like we usually take a train plane, not passengers buy a ticket without check-in process of can bus, if users have direct access to the business system, and bring the fake user information, business system also think that the user login successfully, it is very dangerous