SSO-单点统一登录系统的设计与实现

本文主要基于web类应用展开讨论，提供的是一种通用机制和方法，所以不论何种技术栈都可进行相应的具体实现。

实现目标

可以在相同或跨域环境下完成各应用的统一登录/注销

方案原理

本质上是采用了web应用的会话技术和机制，所以才使得此方案的可操作性和通用性乃至规范性上有了天然的优势。会话追踪主要有Session、Cookie两种实现，背后的原理和机制大家也都非常熟悉。抛开它们的些许差异不谈，共通的思想都是在身份得到认证通过后，保持一个特定的可溯身份标识（Session ID / Cookie字符串），当然了他们都是以HTTP的Cookie部分保存的。又可知，当浏览器禁用了Cookie，为了让Session继续工作，就需要把Session Id附带到url部分来传递。说到这，就引出了我们想要表达的重点，即在应用服务器和统一认证服务器间传递认证信息的字符串标识（姑且称之Token），Token和Session ID我们完全可当作一个同源的东西来看待，也就是说没有额外需求场景下又恰好使用的Session，完全可以拿Session ID直接来用。之所以引出Token，主要是为了将使用Cookie作为用户认证手段的应用统一起来。

系统组件

• 统一认证服务器（sso.com） - 此服务保存关于用户的公共信息，各应用均请求该服务进行登录/注销和身份有效性验证。

• 应用服务器（a.com, b.com） - 此类服务保存用户的具体业务信息和相应的角色权限， 参与到SSO应用群中的各个独立应用站点。

处理流程

• 登录

1. 用户访问a/b.com，本地域检查未登录，跳转至步骤2（本地域自由选择使用Session / Cookie来记录用户登录认证标识）

2. sso.com域检查本地用户登录认证信息，用户是否已登录，如未登录先进行登录，登录成功后记录本地用户登录认证标识（Session或Cookie），并生成保存一个唯一的Token来标识用户，然后在URL中携带以上Token跳转至来源应用域（形式如：a/b.com?token=xxxxxx）

3. a/b.com域如接收到URL中的token串后，请求sso.com提供的验证接口检查token的真实有效性，如有效则同时返回用户的关键身份信息（如用户ID、用户名、头像URL、...）同时保存本地的用户登录认证标识。

• 注销

1. 注销其实可以分成两类场景： （1a）用户从应用a/b.com本地退出，本地域检查已经登录，对本地认证登录认证标识做销毁过期处理，并将URL跳转至sso.com的注销地址（如：sso.com/logout）。（1b）用户从应用a/b.com的外部域退出，对于此种情形的应对，需要在各应用登录后执行一段定时（时长可按实际情况酌情考虑，如希望准实时就将间隔尽量小，灵活掌握）轮询的jsonp脚本携带登录时的Token信息，去请求sso.com检测是否已退出（如：sso.com/checkExist?token=xxxxxx），如检测到为已退出状态，对本地认证登录认证标识做销毁过期处理，但不用再额外通知sso.com了。

2. sso.com本地域退出或接收到来自外部应用的logout的请求后，将本地域相应Token标识用户的登录认证标识做销毁过期处理。

以上即是一套完整的且具通用性的sso解决方案，实现简单而对新搭建或旧有系统的改造几乎无侵入性，只需增加登录和注销时所需的处理逻辑。

补充一点额外的话，有没有觉得这个方案如果往再更大范围去想，是完全可以当作一套更具开放性的三方登录（如：Open ID / Oauth）平台服务，各平台也无需注册，权当成一个需要接入sso应用方对接就可完成。