Preface
Single sign-on is divided into three mechanisms, which are http stateless protocol, session mechanism, and login mechanism.
http stateless protocol
The web application uses the browser/server architecture, http as the communication protocol, http is a stateless protocol, each browser request, the server will be processed independently, as shown in the following figure, there is no relationship between the three requests and responses.
That is, according to the figure above, the http request is a stateless protocol.
Session mechanism
When the browser accesses the request 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 judges whether it is a user from the request by the id.
The server saves the session object in memory, how does the browser save the session id? You might think of two ways
- Request parameter
- The cookie
takes the session id as the parameter of each request. The server receives the request and can naturally parse the parameters to obtain the session id and determine whether it is from the same session. Obviously, this method is not reliable. Then the browser maintains this session id by itself. The browser automatically sends the session id every time an http request is sent. The cookie mechanism is just used to do this. Cookie is a mechanism used by the browser to store a small amount of data. The data is stored in the form of "key/value", and the cookie information is automatically attached when the browser sends an http request
The tomcat session mechanism of course also implements cookies. When accessing the tomcat server, a cookie named "JSESSIONID" can be seen in the browser. This is the session id maintained by the tomcat session mechanism. The request response process using the cookie is shown in the figure below.
Login status
With the session mechanism, the login state assumes that the browser requests the server for the first time to enter a user name and password to verify identity. The user holding this session is a legitimate user when the server gets it. You should mark this session as authorized or logged in. The logo 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 as follows:
Every time a protected resource is requested, the login status in the session object is checked. Only the session with isLogin=true can be accessed. Therefore, the login mechanism is implemented.
Let's start to explain the implementation method
One way to achieve it: parent domain cookie
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 the path starting with "/". In Tomcat, the path attribute defaults to the context path of the current Web application.
If the cookie's domain attribute is set to the parent domain of the current domain, then it is considered a parent domain cookie. Cookie has a characteristic, that is, the cookie in the parent domain is shared by the child domain. In other words, the child domain will automatically inherit the cookie in the parent domain.
Using this feature of Cookie, it is not difficult to think that it is not enough to save the Session ID (or Token) in the parent domain. That's right, we only need to set the domain attribute of the cookie to the domain name of the parent domain (main domain name), and set the path attribute of the cookie to the root path at the same time, so that all subdomain applications can access the cookie. However, this requires that the domain name of the application system must be established under a common main domain name, such as tieba.baidu.com and map.baidu.com, which are both established under the main domain name of baidu.com, then they can pass this Ways to achieve single sign-on.
Implementation method two: certification center
We can deploy a certification center to deal with these issues
The user logs in at the authentication center. After the login is successful, the authentication center records the user's login status and writes the Token into the Cookie.
The application system checks whether there is a Token in the current request. If not, it means that the user is not logged in in the current system, and then the page is redirected to the authentication center. Since this operation will automatically bring the cookie of the certification center, the certification center can know whether the user has logged in according to 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 one before the jump Token is spliced behind the target URL and passed back to the target application system.
After the application system gets the Token, it also needs to confirm the legality of the Token with the certification center to prevent users from forging it. After the confirmation is correct, the application system records the user's login status, writes the Token into the Cookie, and then releases the visit. (Note that this cookie is in 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 is logged in, so it will not What happened to the certification center?
A well-known certification center is ApereoCAS. XXL-SSO
LocalStorage cross-domain implementation
How to share Session ID (or Token) in multiple domains.
Parent domain cookie is indeed a good solution, but does not support cross-domain. So are there any tricks to make cookies pass across domains?
Unfortunately, browsers have increasingly strict cross-domain restrictions on cookies. The Chrome browser also adds a SameSite attribute to Cookies, which almost prohibits the transmission of cookies for cross-domain requests (except hyperlinks), and only when the HTTPs protocol is used, can it be allowed in AJAX cross-domain requests Accept cookies from the server.
However, in the case where the front and back ends are separated, cookies are completely unnecessary. We can choose to save the Session ID (or Token) in the browser's LocalStorage, so that the front-end will take the initiative to save the LocalStorage each time a request is sent to the back-end. The data is passed to the server. These are all controlled by the front-end. All the back-end needs to do is to pass the Session ID (or Token) in the response body 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 gets the Session ID (or Token), in addition to writing it into its own LocalStorage, it can also be written into LocalStorage under multiple other domains by special means.
The sample code is as follows:
// 获取 token
var token = result.data.token;
// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
iframe.remove();
}, 6000);
// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
localStorage.setItem('token', event.data)
}, false);The front-end uses iframe+postMessage() to write the same Token into LocalStorage under multiple domains. Each time the front-end sends a request to the back-end, it will actively read the Token from LocalStorage and carry it in the request. The same token is shared by multiple domains.
I hope it will be helpful for everyone to learn single sign-on, and the friends I like can help forward + follow, thank you!