Three ways to sign in with single sign-on, awesome!

  [[374892]]

This article is reprinted from the WeChat public account "Xiaoming Vegetable Market", written by Xiaoming Vegetable Market. Please contact the Xiaoming Vegetable Market public account to reprint this article.

Preface

Single sign-on is divided into three mechanisms, namely http stateless protocol, session mechanism, and login mechanism.

http stateless protocol

Web applications use the browser/server architecture, with HTTP as the communication protocol. HTTP is a stateless protocol, and the server will independently process each request from the browser. As shown in the following figure, there is no relationship between the three requests and responses. That is, as can be seen from the figure above, HTTP requests are stateless protocols.

Session Mechanism

When the browser accesses the server for the first time, the server creates a session again and sends the data to the browser. The browser saves the session ID, and the server determines whether it is a user based on the ID in the request.

The server saves the session object in memory. How does the browser save the session ID? You may think of two ways.

1. Request Parameters
2. Cookies use the session id as a parameter for each request. When the server receives the request, it can naturally parse the parameter to obtain the session id and use it to determine whether it is from the same session. Obviously, this method is unreliable. Then the browser will maintain the session id itself. The browser automatically sends the session id every time it sends an http request. The cookie mechanism is used to do this. Cookies are a mechanism used by browsers to store small amounts of data. The data is stored in the form of "key/value". When the browser sends an http request, it automatically attaches the cookie information.

The tomcat session mechanism also implements cookies. When accessing the tomcat server, you can see a cookie named "JSESSIONID" in the browser. This is the session ID maintained by the tomcat session mechanism. The request response process using cookies is shown in the following figure

Login status

With the session mechanism, the login state is assumed that the browser needs to enter the username and password to verify the identity when it requests the server for the first time. The server knows that the user holding this session is a legitimate user, and the session should be marked as authorized or logged in. The identification is as follows;

 HttpSession session = request.getSession();
 session.setAttribute( "isLogin" , true );

When the user visits again, he will see the following login status

 HttpSession session = request.getSession();
 session.getAttribute( "isLogin" );

The implemented model is shown below:

Each time a protected resource is requested, the login status in the session object is checked, and only sessions with isLogin=true can access it, so the login mechanism is implemented.

Let's start with the implementation method

Implementation method 1: Parent domain cookies

The scope of the cookie is determined by 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 a path starting with "/". In Tomcat, the path attribute defaults to the context path of the current Web application.

If the domain attribute of a cookie is set to the parent domain of the current domain, it is considered a parent domain cookie. Cookies have a characteristic that the cookies in the parent domain are shared by the child domain. In other words, the child domain automatically inherits the cookies in the parent domain.

With this feature of Cookie, it is not difficult to think that it is enough to save the Session ID (or Token) in the parent domain. That's right, we only need to set the domain attribute of Cookie to the domain name of the parent domain (primary domain name), and set the path attribute of Cookie to the root path, so that all subdomain applications can access this Cookie. However, this requires that the domain name of the application system must be established under a common primary domain name, such as tieba.baidu.com and map.baidu.com, which are both established under the primary domain name of baidu.com, so they can achieve single sign-on in this way.

Implementation method 2: Certification center

We can deploy an authentication center to specifically handle these issues. Users log in to the authentication center uniformly. After successful login, the authentication center records the user's login status and writes the Token into the Cookie. The application system checks whether the current request has a Token. If not, it means that the user has not logged in in the current system, so the page will be redirected to the authentication center. Since this operation will automatically bring the authentication center's Cookie, the authentication center can know whether the user has logged in based on the Cookie. If the authentication 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 already logged in, it will not let the user log in again, but will jump back to the target URL and generate a Token before the jump, spliced ​​behind the target URL, and returned to the target application system.

After the application system obtains the Token, it also needs to confirm the legitimacy of the Token with the authentication center to prevent users from forging it. After confirmation, the application system records the user's login status, writes the Token into the Cookie, and then allows this access. (Note that this Cookie is for the current application system and cannot be accessed by other application systems.) When the user accesses the current application system again, the Token will be automatically brought with him. The application system verifies the Token and finds that the user has logged in, so the authentication center will have nothing to do. Famous authentication centers include ApereoCAS. XXL-SSO

LocalStorage cross-domain implementation

How to share Session ID (or Token) in multiple domains. Parent domain cookies are indeed a good solution, but they do not support cross-domain. So is there any trick to pass cookies across domains? Unfortunately, browsers are increasingly restricting cross-domain cookies. Chrome browser has also added a SameSite attribute to cookies, which almost prohibits all cross-domain request cookies (except hyperlinks), and only when using the HTTPs protocol can it be allowed to accept cookies from the server in AJAX cross-domain requests.

However, in the case of separation of front-end and back-end, it is not necessary to use cookies at all. We can choose to save the Session ID (or Token) in the browser's LocalStorage, and let the front-end actively pass the LocalStorage data to the server every time it sends a request to the back-end. These are all controlled by the front-end, and the back-end only needs 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 fully implemented on the front end. After the front end obtains the Session ID (or Token), in addition to writing it to its own LocalStorage, it can also write it to the LocalStorage of multiple other domains through special means. The sample code is as follows:

 // Get token
 var token = result.data.token; 
 
 // Dynamically create an invisible iframe and load a cross-domain HTML in the iframe
 var iframe = document.createElement( "iframe" );
 iframe.src = "http://app1.com/localstorage.html" ;
 document.body.append(iframe);
 // Use the postMessage() method to pass the token to the iframe
 setTimeout( function () {
    iframe.contentWindow.postMessage(token, "http://app1.com" );
 }, 4000);
 setTimeout( function () {
 iframe.remove();
 }, 6000); 
 
 // Bind an event listener to the HTML loaded by this iframe. When the event is triggered, write the received token data to localStorage
 window.addEventListener( 'message' , function (event) {
    localStorage.setItem( 'token' , event.data)
 }, false );

The front end writes the same Token to LocalStorage under multiple domains through iframe+postMessage(). Before sending a request to the back end each time, the front end will actively read the Token from LocalStorage and carry it in the request, so that the same Token can be shared by multiple domains.