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应用方对接就可完成。