SSO single sign on

1、SSO explain

SSO English full name Single Sign On, Single sign on .SSO In multiple application systems , Users only need to log in once to access all mutual trust application systems .SSO（Single Sign On）_ Baidu Encyclopedia

For example, visit the Netease account center （ Netease email account security center  ） After login Visit the following sites are login status

• Netease live  https://v.163.com
• Netease blog  https://blog.163.com
• Netease Huatian  https://love.163.com
• Netease koala  https://www.kaola.com
• NetEase Lofter http://www.lofter.com

2、 Benefits of single sign on system

1. User perspective  : Users can log in once and use many times , No need to record multiple sets of user names and passwords , worry .
2. System administrator Perspective  : The administrator only needs to maintain a unified account center , convenient .
3. New system development perspective :  When developing a new system, you only need to directly connect to a unified account center , Simplify development process , To save time .

3、 Design objectives

This article is also mainly to explore how to design & Achieve one SSO System

Here are the core functions that need to be implemented ：

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

Two 、SSO Design and implementation

1、 Core applications and dependencies

application / modular / object	explain
Front desk site	The site you need to log in to
SSO Site - Sign in	Provide login page
SSO Site - Log out	Provides access to log off
SSO service - Sign in	Provide login service
SSO service - The login status	Provide login status verification / Login information query service
SSO service - Log out	Provides the user to log off the login service
database	Store user account information
cache	Store user login information , Usually use Redis

2、 Storage and verification of user login status

common Web Framework for Session The implementation of is to generate a SessionId Store in browser Cookie in . And then Session Content is stored in server-side memory , This ken.io Before Session working principle It's also mentioned in . The whole idea is also used for reference . After the user logs in successfully , Generate AuthToken Give it to the client to save . If it's a browser , It's stored in Cookie in . If it's a cell phone App It's stored in App In the local cache . This paper is mainly based on Web Site SSO. When the user is browsing the page that needs to log in , The client will AuthToken Submit to SSO Service validation login status / Get user login information

For the storage of login information , The proposal USES Redis, Use Redis Cluster to store login information , It can guarantee high availability , It can be extended linearly . At the same time, we can also make SSO Services meet load balancing / Scalable requirements .

object	explain
AuthToken	Use it directly UUID/GUID that will do , If there is validation AuthToken The need for legitimacy , Can be UserName+ Timestamp encryption generation , Verify the validity after decryption by the server
login information	Usually it's going to be UserId,UserName cached

3、 The user login / Login verification

• Login sequence diagram

According to the picture above , After the user logs in AuthToken Save in Cookie in . domain=test.com The browser will domain Set to .test.com, This way to access all of *.test.com Of web Site , Will be AuthToken Take it to the server side . And then through SSO service , Complete the verification of user status / Access to user login information

• Access to login information / Login status verification

 

4、 The user to log out

What users have to do when they log out is simple ：

1. Server clear cache （Redis） Login status in
2. The client clears the stored AuthToken

• Log out of the sequence diagram

5、 Cross domain login 、 Log out

As mentioned earlier , The core idea is client storage AuthToken, Server side through Redis Store login information . Since the client is going to AuthToken Stored in Cookie Medium . So the problem to be solved across domains , It's how to solve Cookie Cross domain read-write problem of .

Cookie It's not cross domain  , Like me

The core idea of cross domain solution is ：

• After the login is completed, through callback , take AuthToken Pass to a site other than the primary domain name , The site itself will AuthToken Stored in the current domain Cookie in .
• After the logout is completed, it can be called back , Call the logout page of a non primary domain name site , Complete set Cookie Medium AuthToken Expired operations .
• Cross domain login （ The primary domain name is already logged in ）

  Cross domain login （ The primary domain name is not logged in ）

Cross domain logout  

 

3、 ... and 、 remarks

• About the plan

This design is more to provide implementation ideas . If it involves APP User login, etc , During a visit to SSO The service , Add to APP The signature verification of . Of course , If there is a wireless gateway , Verifying the signature is not a problem .

• About sequence diagrams

The sequence diagram doesn't contain all the scenarios ,ken.io Just the core / Main scene , In addition, for some information that does not affect the understanding of ideas, you can save .