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
- Netease live http://v.163.com
- Netease blog http://blog.163.com
- Netease Huatian http://love.163.com
- Netease Koala https://www.kaola.com
- Netease Lofter http://www.lofter.com
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
|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.
|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
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
4. User login
The things that users need to do when they log out are very simple:
- The server clears the login status in the redis
- The client clears the stored authToken
- Log out sequence diagram
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)
- Cross domain login (primary domain name not logged in)
- Cross domain logout
- 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.