Introduction to cross-origin multi-point SSO (SSO for multiple registration servers)

Multi-Point SSO, which can be understood as SSO with multiple registered servers or distributed SSO, that is, the user registration information is distributed across multiple servers, in fact, this type of technology is relatively mature now, such as Tencent, skepy, interconnected star, and other large-scale applications. For example, the number of Tencent is hundreds of millions, if one server is used for centralized storage or only one cluster is used for centralized authentication, the long wait is intolerable. So we need more SSO. However, I think that Tencent's QQ should not be expressed by multiple SSO technically, and it is actually not the SSO technology, but the P2P protocol of Tencent. In my own experience, in fact, the best example of multi-point SSO (focusing on implementing distributed SSO between cross-domain servers) is the interconnected star platform, we will not continue to discuss the relationship between the confidentiality agreements. We will talk about SSO over multiple points.

Technically speaking, multi-point SSO has the following difficulties:

1. User Authentication labels between multiple registration servers to prevent duplication
2. Location of user registration address
3. Cross-domain authentication status synchronization (all SSO issues to be resolved)
4. Logon logout status issues

For the first point, we can generally refer to the SIP protocol. We divide the user ID into two sections, the previous section is the ID of the registered site and then the Domain Name of the website after @, the structure is similar to the e-mail address such as Alexander-lee@cnblogs.com, assume that cnblogs.com is the site I registered. During registration, I only need to enter Alexander-Lee and then add @ cnblogs.com to my tail automatically. In this way, the minimum limit can be reached for each site registration.

At the same time, this method can also achieve the role of user registration server address, we can use the Domain Name Information to locate the user registration location, or Alexander-lee@cnblogs.com, all the literate people know that they have registered with cnblogs.com.

Then there is the issue of cross-origin authentication status synchronization. This is used as a scheme in the pipeline (I personally do not recommend that you use cross-origin cookies or JS injection technologies, which are easily blocked by strict browsers ).

The last issue is the log off status, which is not mentioned in my original post. It is relatively simple for Single Point SSO. But for Multi-Point SSO, It is very cumbersome because it is necessary to clear the cookies on multiple servers and cannot be completed by using client technologies such as Js. The simplest way is to use non-persistent cookies for all sites and disable all browsers. However, if it is a persistent Cookie, I do not have a good idea. One idea is to set a cookie in the protocol to store all the servers that have logged on, then, at the time of cancellation, the interface page for cancellation will be forwarded once. (This is a stupid solution. We look forward to a simple solution provided by senior engineers ).

In fact, write these things because I saw the http://www.cnblogs.com/chinaxiaofei/archive/2007/09/28/909920.html of the master post, after reading the feeling that there are a lot of questions not talked about, it is not very perfect, so I am looking forward to joint discussion of this post.