preface

Recently, I had dinner with a colleague, and we were talking about the implementation of single sign-on, which was quite controversial. These two days specially spent time to look at the source code, found that there is really a lot of learning! Online single sign-on related articles are mostly in the back-end direction, very few front-end. One is to fill the vacancy, and the other is as a record, so I wrote this article.

1. To jump or not to jump? That’s a problem!

Users only need to log in to any system once to access other trusted application systems. From a technical point of view, the following issues need to be addressed:

  1. Log on to check
  2. Persistent storage
  3. Expired mechanism

Check the login status, first check whether stored in the local sessionStorage/localStorage the user information. If no, check whether there is a valid session between the client and sso server. If no, the SSO login page is displayed.

When a user successfully logs in to the SSO login page, a session is established with the SSO server. The server writes the session ID into the cookie on the SSO login page. Why write cookies instead of other storage methods? Here is an article about persistent storage, do not understand the small friends to read by yourself. When users access other associated applications, this cookie tells the server that they have logged in recently and please allow.

The problem is that cookies are stored in the SSO login page, and cookies are notoriously inaccessible across domains. How do users get cookies in other associated applications?

My initial assumption was that the user would jump to the SSO login page when accessing other associated applications, and the login page would check whether the cookie survived. If it persists, concatenate the cookie to the associated application address and redirect it back. This solution is technically feasible, but has significant drawbacks in terms of user experience: because of two more jumps, the page will refresh twice on the first load, and the white screen waits longer.

Is there a way to get cookies without going to the SSO login page? Not technically! However, we can achieve sensorless jump and obtain cookies through technical means.

2.XSS and cross-window communication

XSS cross-site scripting is a security vulnerability. During the period when the attacked website remains alive, the attacker can inject malicious code into the target website to steal cookies and achieve the purpose of impersonating the user identity of the target site.

Lu Xun once said: “Guns and guns can be used to harm people or help people, so is IT technology.” Using the principle of XSS cookie stealing, the script creates an iframe sub-window pointing to the sso login page address in the main window, and infuses the code to steal cookies into it, and then carries out cross-window communication through postMessageAPI to send cookies to the main window.

Remember the session ID mentioned above, when the user obtains the cookie, it means that the user has obtained the session ID and sends a request with the cookie to the SSO server to verify whether the session is expired. If it expires, go to the SSO login page to log in. Otherwise, the unique user credential is returned. With user unique credentials, we can access associated application content without logging in.

3. Write at the end

The core of SSO implementation on web side is to figure out the design and architecture of single sign-on process, and the key is to solve the problem of cross-browser information transfer. It’s been a long, long time since last time. If you insist on reading this article and find it useful, please feel free to like and comment on it and share it with more people in need! Your support will be our continuous output power ~