SSO single sign on idea

SSO (Single Sign On)

What is single sign on:

In large Internet companies, there will be multiple systems and projects. Although these projects belong to the same company, the projects themselves are actually independent. Can multiple systems share the same user authentication data?

SSO single sign on is to do this. Various projects trust each other and log in in to any system. The user's authentication information will be cached locally. When the user visits other sites, the authentication information can be reused, avoiding the trouble of re login and improving the user experience

Logic of XXL single sign on Implementation

The official website of XXL is: https://www.xuxueli.com/xxl-sso/

The overall implementation idea is the cross domain implementation of URL + reading and writing cookies or tokens. What kind of implementation method is this? This is related to the processing of cookies by the browser. When we use browsing to visit a site, the background logic may write cookies to the browser. As we all know, the role of this cookie is an identity. When the user visits the same site again, the browser will automatically carry the cookie under the domain name corresponding to the site

As shown in the figure below, this cookie belongs to xxlssoclient1 In other words, users will not carry this cookie when visiting other sites

**From the above analysis, we can see that the limitation of single sign on is obvious. It cannot cross domain browsers, because the credentials of the authorization center are cookies stored in the user's browser**

get down to business

User request login page

As soon as the server starts, it will first initialize the filter. Use this filter to filter all the user's requests, verify whether the user has permission to access the current system, and if not, forward the user's request to the authorization center. The forwarding path is as follows:

Add redirect_ The intent of the URL parameter is obvious, that is, to redirect back from the authorization center

If the authorization center finds that the currently accessed user does not have any available information, it will return a login page to the user

User login

The user sends the login request to the authorization center on the login page, which will go through the following process

I have marked the process in the figure above. It is worth noting that the second step is to write the user's authorized signature back to the user's browser in advance, because there is an interceptor in the client the user wants to access, which specifically intercepts whether the user's request carries a legal signature. Here, after writing the user's request to the browser, The next time the user accesses the client, he will have a legal identity

The second note is that the redirection operation is initiated in the authorization center. The redirected URL is as follows:

Sessionid will be carried in the URL to ensure that the request can be successfully verified in the client

How do users access other applications that trust each other without repeated authorization, as shown in the figure below

Suppose the URL of the client is:

The URL of client2 is

If client and client2 share an authorization center, we first log in with client on the browser After successful login, return to the login page

Then we continue to visit the URL of client2 on this browser. You can see the difference between the URLs of client and client2: the domain name is different. Of course, I modify the host name locally for simulation. This is also the case in actual production. For example, a large Internet company must have different projects, and different projects have different domain names, Then we can now access different domain names and still complete the login

In combination with the above figure, when a user visits client2, because the user has never logged in, he is intercepted by the interceptor of client2, and then redirects the user's request to the authorization center. However, this redirection is very special because it will carry the cookie written to the user's browser during the first visit to the client. This is easy. Authorization knows this cookie, So the authorization center takes this cookie and takes out the user's information from redis, and then writes the authorization sessionid generated for the user back to the user's browser. These written back authorization IDs are stored in the browser http://xxlssoclient2.com Under the domain name, and then redirect the request back to client2. This time, the directed request URL will grow like this

With sessionid, the whole process comes down, and the client does not need to log in repeatedly Single sign on is realized

single logout

Logoff is to delete the user's information in the redis cache. (in the implementation of XXL, the authorization center and all clients share a redis database). In fact, deletion is relatively simple. As long as we ensure that the cached user's information in redis can be deleted, it is OK. Whether the cookie in the user's browser is deleted or not is of little significance, If there is no cookie in redis that matches the cookie completely, the request will still be sent to the login page by the framework