单点登陆（SSO）的设计&实现思路

1、前言

一、SSO说明

SSO英文全称Single Sign On，单点登陆。SSO是在多个应用系统中，用户只须要登陆一次就能够访问全部相互信任的应用系统。https://baike.baidu.com/item/...

例如访问在网易帐号中心（http://reg.163.com/ ）登陆以后
访问如下站点都是登陆状态

• 网易直播 http://v.163.com
• 网易博客 http://blog.163.com
• 网易花田 http://love.163.com
• 网易考拉 https://www.kaola.com
• 网易Lofter http://www.lofter.com

二、设计目标

本篇文章也主要是为了探讨如何设计&实现一个SSO系统

如下为须要实现的核心功能：

• 单点登陆
• 单点登出
• 支持跨域单点登陆
• 支持跨域单点登出

2、SSO设计与实现

一、核心应用与依赖

应用/模块/对象	说明
前台站点	须要登陆的站点
SSO站点-登陆	提供登陆的页面
SSO站点-登出	提供注销登陆的入口
SSO服务-登陆	提供登陆服务
SSO服务-登陆状态	提供登陆状态校验/登陆信息查询的服务
SSO服务-登出	提供用户注销登陆的服务
数据库	存储用户帐户信息
缓存	存储用户的登陆信息，一般使用Redis

二、用户登陆状态的存储与校验

常见的Web框架对于Session的实现都是生成一个SessionId存储在浏览器Cookie中。而后将Session内容存储在服务器端内存中，这个 ken.io 在以前Session工做原理中也提到过。总体也是借鉴这个思路。
用户登陆成功以后，生成AuthToken交给客户端保存。若是是浏览器，就保存在Cookie中。若是是手机App就保存在App本地缓存中。本篇主要探讨基于Web站点的SSO。
用户在浏览须要登陆的页面时，客户端将AuthToken提交给SSO服务校验登陆状态/获取用户登陆信息

对于登陆信息的存储，建议采用Redis，使用Redis集群来存储登陆信息，既能够保证高可用，又能够线性扩充。同时也可让SSO服务知足负载均衡/可伸缩的需求。

对象	说明
AuthToken	直接使用UUID/GUID便可，若是有验证AuthToken合法性需求，能够将UserName+时间戳加密生成，服务端解密以后验证合法性
登陆信息	一般是将UserId，UserName缓存起来

三、用户登陆/登陆校验

• 登陆时序图

按照上图，用户登陆后Authtoken保存在Cookie中。 domian= test. com
浏览器会将domain设置成 .test.com，
这样访问全部*.test.com的web站点，都会将Authtoken携带到服务器端。
而后经过SSO服务，完成对用户状态的校验/用户登陆信息的获取

• 登陆信息获取/登陆状态校验

四、用户登出

用户登出时要作的事情很简单：

1. 服务端清除缓存（Redis）中的登陆状态
2. 客户端清除存储的AuthToken

• 登出时序图

五、跨域登陆、登出

前面提到过，核心思路是客户端存储AuthToken，服务器端经过Redis存储登陆信息。因为客户端是将AuthToken存储在Cookie中的。因此跨域要解决的问题，就是如何解决Cookie的跨域读写问题。

解决跨域的核心思路就是：

• 登陆完成以后经过回调的方式，将AuthToken传递给主域名以外的站点，该站点自行将AuthToken保存在当前域下的Cookie中。
• 登出完成以后经过回调的方式，调用非主域名站点的登出页面，完成设置Cookie中的AuthToken过时的操做。
• 跨域登陆（主域名已登陆）

• 跨域登陆（主域名未登陆）

• 跨域登出

3、备注

• 关于方案

此次设计方案更可能是提供实现思路。若是涉及到APP用户登陆等状况，在访问SSO服务时，增长对APP的签名验证就行了。固然，若是有无线网关，验证签名不是问题。

• 关于时序图

时序图中并无包含全部场景，ken.io只列举了核心/主要场景，另外对于一些不影响理解思路的消息能省就省了。

• 前置知识

一、Session的工做原理和使用经验：https://ken.io/note/session-p...
二、Cookie的特色和使用经验/建议总结：https://ken.io/note/cookie-fe...

以上，若有疑问，欢迎联系我：https://ken.io/home/about

---

本文首发于个人独立博客：https://ken.io/note/sso-desig...