Today write an article about the implementation of multi – domain single sign-on.

In this scenario, the company has multiple sites with different domain names, and we expect users to log in to any site, but also log in to other sites when they open them. This process is single sign-on.

Because multiple sites use the same user system, single sign-on can eliminate the need for users to log in repeatedly, allowing users to switch between sites more smoothly, or even without awareness.

Single sign-on (SSO) is to synchronize the login status of one site to several other sites.

We are divided into two parts, first said a single site login process, in the process of synchronization login state.

Login Related Architecture

  • The server usesnodejs, cache adoptsredis 。
  • User login credentials are based onsession 的 cookiesMaintain, adoptcookieAs a login certificate is currently the more mainstream way.
  • sessionInformation withredisBearing, from the data level,redisStored in thesessionThe object’skeyiscookieIn thevalue
  • keyIs made up ofUUIDUnique identifier generated
  • In order to ensure thatsession 与 cookieKeep the correspondence,sessionObject creation and modification trigger server writing to the browsercookie

The login process

Let’s start by looking at the login process for a single site

  1. The first time the user opens the site, the server generatessessionObject, at which pointsessionThe server writes to the browser at the same timecookie
  2. The user triggers the login operation
  3. After the login logic is processed, user information is generated and written to the serversessionObject to update the cacheredisSo let’s draw a picture like this

Synchronous login state

Once a site is logged in, the next step is how to make other sites logged in as well. Since the login state is determined by the cookie and session, and the cookie is written by the session, that is to say, as long as the session is synchronized to other sites, other sites as long as they get the session, Cookies can be created or updated on that domain so that two sites under different domains have the same login information.

So, synchronization login state is really a question of how to synchronize sessions.

Our session uses REDis as the carrier, so other sites can create their own session objects as long as they can obtain user information stored in Redis.

That’s right! The problem of how to synchronize session becomes how to let other sites get user information from Redis, that is, how to let other sites know the Redis key that stores the user information

At this point, the problem is obvious: how to transfer user credentials between different sites.

For description purposes, we assume that there are two sites, site A and site B. Because the domain names of sites A and B are different, cookies cannot be shared based on the same origin policy, so we take the initiative to request and send the unique credentials of users through the interface. The general process is as follows

  1. After completing the login logic, site A returns the user credentials to the browser. For security, the credentials are encrypted before being transmittedAESorRSA
  2. After obtaining the credentials, the client at site A invokes the synchronous login interface provided by site B to transfer the credentials
  3. The server of site B obtains the credentials, decrypts them, queries the user information in the cache, and createssessionObject, written under the domain name of site Bcookieinformation
  4. The login status of site B is synchronized.

Based on the above, we perfected the synchronous timing diagram

Synchronization login scenario

The above describes the synchronization process when users log in for the first time. Other scenarios need to be considered. For example, if the login status obtained from site B is invalid, users need to go to site A to synchronize the login status when accessing site B.

The pages on site B are divided into two types: one is accessible only by login state, and the other is accessible without login state.

In the first case, you need to redirect to site A, but why detour back to site A? Because we don’t know whether or not A site login state also failed, so you need to return to A site to determine A login site of the current state, if A site login state also fail, then go to the login page to log back in and if A site is on state, so as long as doing A synchronous login state operation.

In the second case, although page B can be viewed without login state, enterprise websites often mark the login state of users in the head part of the page. Therefore, in order to make the display of this part normal, we can update the login state asynchronously on the current page.

So let’s draw it a little bit clearer, like this

If there are other scenarios, the logic is similar to this one, and the essence is to get a credential and update the site cache.

Cross-domain request

Because site A requests the interface under domain name B, cross-domain problems may occur. The common solutions to cross-domain problems are as follows

  1. JSONPIt’s a very common and universal way
  2. ImageusingImage srcYou can bypass the same-origin policy, so by building oneImageSending requests is also possible, and the server does not need to make many changes.
  3. CORSOlder browsers don’t support it and need to be set up on the server sideAccess-Control-Allow-OriginAllows requests from any domain or specified domain to obtain data from the current server.

Session Object Design

The server mainly focuses on the session object. I have written a detailed article about the principle and concrete implementation of the session based on KOA2, portal: Node Project – to build an excellent session mechanism

summary

The article is mainly based on the scheme, will not put on the detailed code, in fact, with a specific scheme, the implementation of the code is not difficult.

There must be other great solutions to multi-site single sign-on. Welcome to the comments section