不管是什么公司，只要产品数量大于一个，那么单点登录势必是绕不过去的一个问题。作为前端程序员，我们对其虽然接触不多，但适当的了解还是必要的。本文就来谈谈单点登录相关的问题。
前置知识
了解 SSO，最好具备以下知识。当然，如果不是特别熟，也不影响阅读。
cookie及session
浏览器同源策略及跨域
了解登录系统的构成
什么是 SSO 与 CAS?
SSO
SSO 是英文 Single Sign On 的缩写，翻译过来就是单点登录。顾名思义，它把两个及以上个产品中的用户登录逻辑抽离出来，达到只输入一次用户名密码，就能同时登录多个产品的效果。
使用 SSO 的优点很明显：
提升用户体验。就以我厂为例。我厂有两个产品，丁香人才网和丁香园论坛，假如你是我厂用户，肯定无法忍受登录丁香园论坛的时候输入一次用户名密码，登录人才网又要输入一次用户名密码吧？
避免重复开发。假如你是我厂后端，每天任务都饱和的不行，肯定无法忍受到人才网开发一套登录逻辑，到论坛又开发一套登录逻辑吧？
提升安全系数
假如你是我厂运维，发现了一个安全隐患需要紧急修复。你肯定无法忍受给茫茫多的产品后端都发一封邮件，责令修复吧？万一漏了一个呢？
如果你想学习前端，可以来这个Q群，首先是291，中间是851，最后是189，里面可以学习和交流，也有资料可以下载。
CAS
SSO 仅仅是一种架构，一种设计，而 CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。当然，除了 CAS 之外，实现 SSO 还有其他手段，比如简单的 cookie。CAS （Central Authentication Service）中心授权服务，本身是一个开源协议，分为 1.0 版本和 2.0 版本。1.0 称为基础模式，2.0称为代理模式，适用于存在非 Web 应用之间的单点登录。
同域 SSO如图，同域 SSO 是最简单的一种情况。此时，两个产品都是在一个域名下，单点登录是很自然的选择。我们来捋一捋步骤，搞清楚这里的步骤是理解后文的基础，千万不要跳过。
用户访问产品 a，向 后台服务器发送登录请求。
登录认证成功，服务器把用户的登录信息写入 session。
服务器为该用户生成一个 cookie，并加入到 response header 中，随着请求返回而写入浏览器。
该 cookie 的域设定为 dxy.cn。
下一次，当用户访问同域名的产品 b 时，由于 a 和 b 在同一域名下，也是 dxy.cn，浏览器会自动带上之前的 cookie。此时后台服务器就可以通过该 cookie 来验证登录状态了。
实际上，这种场景就是最简单最传统的登录操作。虽然我们把产品 a 和 b 人为分开了，但由于它们在同域上，就算看成是同一产品的不同类目也未尝不可。我们没有设置独立的 SSO 服务器，因为业务后台服务器本身就足以承担 SSO 的职能。
同父域 SSO
同父域 SSO 是同域 SSO 的简单升级，唯一的不同在于，服务器在返回 cookie 的时候，要把cookie 的 domain 设置为其父域。比如两个产品的地址分别为 a.dxy.cn 和 b.dxy.cn，那么 cookie 的域设置为 dxy.cn 即可。在访问 a 和 b 时，这个 cookie 都能发送到服务器，本质上和同域 SSO 没有区别。
.跨域 SSO
可以看到，在上面两种情况下，我们都没有专门设置 SSO 服务器。但是当两个产品不同域时，cookie 无法共享，所以我们必须设置独立的 SSO 服务器了。这个时候，我们就是通过标准的 CAS 方案来实现 SSO 的。
详解CAS
CAS 1.0 协议定义了一组术语，一组票据，一组接口。
术语：
Client：用户。
Server：中心服务器，也是 SSO 中负责单点登录的服务器。
Service：需要使用单点登录的各个服务，相当于上文中的产品 a/b。
/login：登录接口，用于登录到中心服务器。
/logout：登出接口，用于从中心服务器登出。
/validate：用于验证用户是否登录中心服务器。
/serviceValidate：用于让各个 service 验证用户是否登录中心服务器。
