Three implementation methods of single sign on


Excerpt fromJava learner communityAn article for everyone to learn fromOriginal address

  • preface
  • Implementation method 1: parent domain cookie
  • Implementation mode 2: Certification Center
  • Implementation method 3: localstorage cross domain
  • Supplement: domain name classification


stayB/SIn the system, the login function is usually based onCookieTo achieve. When the user logs in successfully, the login status is generally recorded in theSessionOr issue a certificate to the userToken, either way, you need to save some information on the client(Session IDorToken)And ask the client to carry them in each subsequent request. In such a scenario, using cookies is undoubtedly the most convenient, so we generally use cookiesSessionofIDorTokenSave toCookieWhen the server receives the request, it passes the verificationCookieTo determine whether the user logs in.

Single sign on (SSO) refers to that in multiple application systems under the same account platform, users can access all mutually trusted application systems only by logging in once. For example, Baidu Post Bar and Baidu map are two different application systems of Baidu company. If a user logs in to Baidu Post Bar and does not need to log in again when he visits Baidu map, it shows that single point registration has been realized between Baidu Post Bar and Baidu map.

The essence of single sign on is to share the login status in multiple application systems. If the user’s login status is recorded in the session, to share the login status, you must first share the session. For example, you can serialize the session into redis, let multiple application systems share the same redis, and directly read redis to obtain the session.

Of course, this is not enough, because different application systems have different domain names. Although the session is shared, the session ID is often saved in the browser cookie, so there are scope restrictions and cannot be transmitted across domain names, that is, after the user logs in to, The session ID will be automatically carried in the request header only when the browser accesses When the browser accesses, the session ID will not be brought in. The key to single sign on is how to share the session ID (or token) in multiple domains.

Implementation method 1: parent domain cookie

Before we implement it, let’s talk about the scope of cookies.

The scope of a cookie is determined by both the domain attribute and the path attribute. The valid value of the domain attribute is the domain name / IP address of the current domain or its parent domain. In tomcat, the domain attribute defaults to the domain name / IP address of the current domain. The valid value of the path attribute is the path starting with “/”. In tomcat, the path attribute defaults to the context path of the current web application.

If the domain property of the cookie is set to the parent domain of the current domain, it is considered to be a parent domain cookie. One feature of cookies is that the cookies in the parent domain are shared by the child domain. In other words, the child domain will automatically inherit the cookies in the parent domain.

Taking advantage of this feature of cookies, it is not difficult to think of saving the session ID (or token) to the parent domain. Yes, we only need to set the domain attribute of the cookie to the domain name (primary domain name) of the parent domain and the path attribute of the cookie to the root path, so that all child domain applications can access the cookie. However, this requires that the domain name of the application system should be established under a common main domain name, such as and They are all established under the main domain name, so they can realize single sign on in this way.

Summary: this implementation method is relatively simple, but it does not support cross primary domain names.

Implementation mode 2: Certification Center

We can deploy an authentication center, which is an independent web service specially responsible for processing login requests.

Users log in at the authentication center uniformly. After successful login, the authentication center records the user’s login status and writes the token into the cookie( Note that this cookie belongs to the authentication center and cannot be accessed by the application system.)

The application system checks whether there is a token in the current request. If not, it indicates that the user has not logged in in the current system, and then the page will jump to the authentication center. Since this operation will automatically bring the cookie of the authentication center, the authentication center can know whether the user has logged in according to the cookie. If the Certification Center finds that the user has not logged in, it will return to the login page and wait for the user to log in. If it finds that the user has logged in, it will not let the user log in again, but will jump back to the target URL, generate a token before the jump, splice it behind the target URL and return it to the target application system.

After the application system gets the token, it also needs to confirm the legitimacy of the token to the authentication center to prevent users from forging. After confirmation, the application system records the user’s login status, writes the token into the cookie, and then releases the access( Note that this cookie belongs to the current application system and cannot be accessed by other application systems.) When the user accesses the current application system again, it will automatically bring this token. The application system verifies the token and finds that the user has logged in, so there will be no authentication center.

By the way, here are two open source implementations of certification centers:

  • Apereo CAS is an enterprise single sign on system, in which CAS means “central authentication service”. It was originally a project of Yale University Laboratory, and later transferred to jasig organization. The project was renamed jasig CAS. Later, the organization was incorporated into apereo foundation, and the project was renamed apereo CAS.

  • Xxl-sso is a simple single sign on system, which was developed by Xu Xueli, a public comment engineer. The code is relatively simple and there is no security control. Therefore, it is not recommended to apply it directly in the project. It is listed here for reference only.

Conclusion: this implementation method is relatively complex, supports cross domain and has good scalability. It is a standard practice of single sign on.

Implementation method 3: localstorage cross domain

Earlier, we said that the key to single sign on is how to share session IDs (or tokens) in multiple domains.

Parent domain cookies are indeed a good solution, but cross domain cookies are not supported. So are there any strange techniques that can make cookies pass across domains?

Unfortunately, the browser’s cross domain restrictions on cookies are becoming more and more strict. Chrome browser also adds a samesite attribute to cookies, which prohibits cookie delivery of almost all cross domain requests (except hyperlinks), and it may be allowed to accept cookies from the server in Ajax cross domain requests only when HTTPS protocol is used.

However, when the front end and the back end are separated, cookies can not be used. We can choose to save the session ID (or token) to the browser’s localstorage, so that the front end can actively transfer the data of localstorage to the server every time it sends a request to the back end. These are controlled by the front end. What the back end needs to do is to put the session ID (or token) in the response body and pass it to the front end after the user logs in successfully.

In such a scenario, single sign on can be implemented on the front end. After the front end obtains the session ID (or token), it can write it to its own localstorage, and it can also write it to localstorage under multiple other domains through special means.

The key codes are as follows:

//Get token

The front end writes the same token to the localstorage under multiple domains through iframe + postmessage(). Each time before sending a request to the back end, the front end will actively read the token from the localstorage and carry it in the request. In this way, the same token is shared by multiple domains.

Conclusion: this implementation method is completely controlled by the front end, requires little back-end participation, and also supports cross domain.

Supplement: domain name classification

From a professional perspective (according to the definition in computer network),. Com and. CN are primary domain names (also known as top-level domain names),. and are secondary domain names, and are tertiary domain names, and so on. Level N domain names are the direct sub domain names of level n-1 domain names.

From the perspective of users, the primary domain name that can support independent filing is generally used as the primary domain name, such as and, which can be called the primary domain name, and the direct sub domain name established under the primary domain name is used as the secondary domain name, such as

To avoid ambiguity, I will use the term “primary domain name” instead of “primary domain name”.


This work adoptsCC agreement, reprint must indicate the author and the link to this article