Design and implementation of single sign on

Time:2021-7-4

1、 Preface

1. SSO description

SSO English full name single sign on, single sign on. SSO is in multiple application systems, users only need to log in once to access all mutual trust application systems.https://baike.baidu.com/item/SSO/3451380

For example, visit the Netease account center(http://reg.163.com/ ) After login
Access to the following sites is login status

2. Design objectives

This article is mainly to explore how to design and implement an SSO system

The following are the core functions to be realized:

  • Single sign on
  • Single sign out
  • Support cross domain single sign on
  • Support cross domain single sign out

2、 Design and implementation of SSO

1. Core applications and dependencies

Design and implementation of single sign on

Application / module / object explain
Front desk site Sites to log in to
SSO site – login Provide login page
SSO site – logout Provides an entry to log off
SSO Service – login Provide login service
SSO Service – login status Provide login status verification / login information query service
SSO Service – logout Provide the service of user log off
database Store user account information
cache Store user login information, usually using redis

2. Storage and verification of user login status

Common web frameworks forSessionThe implementation of is to generate a sessionid and store it in the browser cookie. Then, the session content is stored in the server-side memory, and the ken.io is beforeHow session worksIt’s also mentioned in. The whole is also drawing on this idea.
After the user logs in successfully, the authToken is generated and handed over to the client for saving. If it’s a browser, it’s stored in a cookie. If it is a mobile app, it will be saved in the app local cache. This article mainly discusses SSO based on Web site.
When the user browses the page to login, the client submits the authToken to the SSO service to verify the login status / obtain the user login information

For the storage of login information, it is recommended to use redis cluster to store login information, which can ensure high availability and linear expansion. At the same time, SSO services can meet the requirements of load balancing / scalability.

object explain
AuthToken You can use UUID / guid directly. If you need to verify the validity of the authToken, you can encrypt the user name + timestamp and verify the validity after the server decrypts it
login information Usually, the user ID and user name are cached

3. User login / login verification

  • Login sequence diagram

Design and implementation of single sign on

According to the above figure, the authToken is saved in the cookie after the user logs in. domian= test. com
The browser will set the domain to. Test. Com,
In this way, when visiting all the web sites of *. Test.com, the authToken will be carried to the server.
Then, through SSO service, the verification of user status and the acquisition of user login information are completed

  • Login information acquisition / login status verification

Design and implementation of single sign on

4. User login

The things that users need to do when they log out are very simple:

  1. The server clears the login status in the redis
  2. The client clears the stored authToken
  • Log out sequence diagram

Design and implementation of single sign on

5. Cross domain login and logout

As mentioned earlier, the core idea is to store the authToken on the client side and the login information on the server side through redis. Because the client stores the authToken in the cookie. So the problem to be solved is how to read and write cookies across domains.

The core idea to solve cross domain problem is as follows:

  • After login, the authToken is passed to the site outside the primary domain name by callback, and the site saves the authToken in the cookie of the current domain.
  • After the completion of logout, call the logout page of the non primary domain name site by callback to complete the operation of setting the expiration of the authToken in the cookie.
  • Cross domain login (primary domain name is logged in)

Design and implementation of single sign on

  • Cross domain login (primary domain name not logged in)

Design and implementation of single sign on

  • Cross domain logout

Design and implementation of single sign on

3、 Remarks

  • About the program

This design is more to provide ideas for implementation. If it involves app user login and other situations, when accessing SSO services, it is good to add signature verification for app. Of course, if there is a wireless gateway, verifying the signature is not an issue.

  • On the sequence diagram

The sequence diagram does not include all scenarios. Ken.io only lists the core / main scenarios. In addition, it can save some messages that do not affect the understanding idea.