Single sign-on (SSO) When we search for single sign-on, we find many articles, but these articles are generally based on a common scenario description and are often more complex in their respective business environments. In this article, I’ll describe a scenario for implementing single sign-on.

Single sign-on (SSO) SSO allows users to log in once to access all trusted applications in multiple applications. It includes a mechanism to map this primary login to another login for the same user in another application. It is one of the more popular enterprise business integration solutions.

background

In the early stage of enterprise development, a domain name site can carry independent business. However, with the exploration of new business, enterprises will apply for a new domain name for the function bearer of this part of the new business, on the one hand to distinguish, on the other hand to meet regulatory requirements. And need to get through the original site user system in this mode. There are two main types of new independent domain names:

  1. The original site is www.a.com and the new independent domain name is new.a.com.
  2. The original site is www.a.com, the new independent domain name is www.b.com;

For the first scenario, we generally use the shared session mode to enable users to jump between different domain names without repeated login. The specific implementation is mainly to set the domain of sessionID of user login state in cookies as.a.com.

This scenario is relatively simple and can be implemented by switching between the old and new modes. By default, the sessionId domian is www.a.com. If you have visited www.a.com before and the sessionId domian is www.a.com was not cleared during login, then access the site www.a.com. The browser will pass two session ids with the same name to the server. Because they are key-values, the server cannot tell which one is the new one and which one is the old one. If the old one is selected, the user’s login status cannot be obtained. To solve this problem, either set the old domian (www.a.com) to expire when setting the sessionId or use a new sessionId key. For details, see set-cookies.

This scenario is used a lot on our mobile site. For example, the main site is www.a.com and the mobile site is m.a.com.

# set domian to sessionId of.a.com
Set-Cookie: sessionId=a3fWa; Domain=.a.com; Secure; HttpOnly

# set the sessionId with domian as www.a.com to expire
Set-Cookie: sessionId=a3fWa; Domain=www.a.com; expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly
Copy the code

We will focus on the second scenario. In this scenario, the user is not aware of the situation. The following requirements must be met:

  1. After site A logs in, site B synchronizes the login status.
  2. If the login page is not required for site B, you need to actively synchronize the login mode for site A.
  3. If you need to access the login page of site B, you need to go to site A to synchronize the login mode.

Procedure 1: Synchronize the login status from site A to site B

Above is the sequence diagram of the active synchronous login state. The ticket in the picture is stored primarily in Redis. You can store tickets in other storage media or even in application running memory, but it is important to note that tickets should be valid once and should be cleared after use. Since our site B is also under its own control and the read and write performance of Redis is quite superior, a and B connect and read the same Redis. If site B is not controlled, you can send a request to site A on the background of site B to query the valid status of ticket. The specific process is as follows:

  1. The login page for users to visit a.com;
  2. Enter the user name and password to log in and verify the user in the background. After the user succeeds, the SESion of site A is generated and a ticket is generated and put into Redis.
  3. Login page After a successful login, get the ticket and send a cross-domain request (JSONP or Image) to b.com.
  4. After site B obtains ticket, check whether redis exists, set session at site B, and delete ticket.
  5. After the cross-domain request returns, continue with other operations, such as redirecting to the user center, home page, etc.

Process 2: Site B actively synchronizes the login status of site A without the login page

Site A and site B are independent of each other. Assume that the session expiration time of each site is half an hour. If site A is accessed for 30 minutes, the session continues. The specific process is as follows:

  1. Users do not need a login page to access B.com;
  2. If the current site user is not logged in, send an asynchronous JSONP request to a.com.
  3. If the a.com is not logged in, do not perform any operations. If you have logged in, generate ticket information as in the previous process.
  4. After receiving ticket, site B is requested to synchronize the login status, and site B generates session.
  5. After the synchronization is successful, refresh the current page.

Procedure 3: The login page of site B is redirected to site A to synchronize the login mode.

The same as flow 2, this scenario is also caused by the failure to visit and log in site B for a long time. Different from flow 2, this scenario refers to the mode of 302 directly jumping to the page synchronization, which is judged by the background and suitable for the background to directly display the page. If it is a purely static page, please use Flow 2, the specific flow is as follows:

  1. If you need to log in to b.com, you are returned to the status synchronization page of “Switching to Site A”.
  2. Site A status synchronization page Determine the login status of the site. If the site is not logged in, go to the login page of site A. The login process is the same as process 1.
  3. JSONP login status is synchronized to site B, and site B generates a session.
  4. After site B is successfully synchronized, the login page of site b.com is displayed.

conclusion

The above processes are mainly for SSO process solutions for various scenarios. According to the initiator, they can be divided into two types: active synchronization and passive synchronization. In active synchronization, the authentication site obtains the ticket from the authentication site and synchronizes its own login mode. In passive synchronization, the authentication site synchronizes the login mode from the current site.

Generally online materials will have a dedicated site for authentication login, such as a.com and B.com sites from sso.a.com to obtain authentication status. In fact, in this article, site A is used as sso site, the principle is the same.

In order to implement this scheme, business development colleagues do not need to pay attention to the implementation details of this part and write corresponding synchronization code. We put it into the overall framework and mainly do the following two things:

  1. Package front-end login script (support NPM reference, webpack directly), after login to do active site synchronization, business colleagues in the need to log in the scene, directly call method and do other operations in the callback function;
  2. Using a template engine such as EJS or PUG, place the synchronization of process 2 into a common template from which other pages are created.

For more information about SSO authentication, please refer to OAuth2’s process. This process is more mature in terms of security when used for authentication between untrusted sites, and it is also the current authentication process used by wechat.

FYI:

Single sign-on (SSO) look at this article is enough SSO single sign-on three cases of implementation in detail wechat web page authorization