现在很多大的互联网公司都会有很多的应用，比如以下是淘宝网的截图：
天猫 聚划算 头条等都是不同的应用，有的甚至采用完全不同的域名，但是所有在淘宝注册的用户都是使用的一套用户名和口令，如果在这些系统直接切换做不到登陆状态的同 步，体验是非常差的。再举个栗子，很多公司内部系统也有很多个，比如HR系统，财务系统，考勤系统等等，如果员工在一个系统登陆了，跳转到另外一个系统还 需要登陆，就会让人很不爽...
基于此，SSO(Single Sign On)应运而生。当然，我们来现实这个需求的方法有很多种，使用Cookie是其中比较简单的方式，主要需要解决的问题是:Cookie是不能跨域传递的，如何将一个域的Cookie通知给其它应用(不在同一个域)？
so，如果你对cookie机制不太熟悉，请先google，并大致了解为什么cookie会设计成不能跨域等相关问题。
SSO有以下几种方式实现
当我们的子系统都在一个父级域名下时，我们可以将Cookie种在父域下，这样浏览器同域名下的Cookie则可以共享，这样可以通过Cookie加解密的算法获取用户SessionID，从而实现SSO。
但是，后面我们发现这种方式有几种弊端：
a. 所有同域名的系统都能获取SessionID，易被修改且不安全；
b. 跨域无法使用。
这种实现的SSO有以下几个步骤：
a. 用户访问某个子系统，发现如果未登录，则引导用户跳转到SSO登录页面；
b. 判断SSO是否已经登录；
c. 如果已经登录，直接跳转到回调地址，并返回认证ticket；
d. 如果未登录，用户正确输入用户名/密码，认证通过跳转到回调地址，并返回认证ticket；
e. 子系统获取ticket，调用SSO获取用户uid等信息，成功后让用户登录。
前面已经说了，如何通过Cookie来实现SSO，主要是如何解决跨域问题。首先来谈谈Set-Cookie中的domain属性。
为了让Http协议在一定程度上保持上下文，server在响应的头部可以加入Set-Cookie来写入一些数据到客户端，Set-Cookie中的domain字段用来表示这个cookie所在的域。
栗子：
我们访问www.cookieexm.com，如果server在返回头部中加入了Set-Cookie,如果不指定domain,那么默认这个cookie的域就是www.cookieexm.com，也就是只有访问www.cookieexm.com时客户端才会把这个cookie返给服务端。
如果我们指定domain为.cookieexm.com，那么客户端在访问以下域名：www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com 时都能够把cookie返回。
所以，我们得出一条结论：客户端对cookie的domain的匹配是从结尾进行匹配的，有了这个基础，我们就可以实现我们的SSO登陆了。
cookie中需要注意的
假设我们需要在如下子系统 **.a1.a2 **.b1.b2 **.c1.c2间实现单点登录，首先我们需要一个专门用于单点登陆的认证系统(sso.s1.s2)。假设目前系统处于未登录状态，访问www.a1.a2为例：
分别看一下每个步骤作用：
说明:
业务认证系统不一定存在，有些不是太敏感的系统可以直接从SSO Authorization重定向到业务系统，并把SSO的认证信息带过去。
承接上文，此时，如果用户访问www.b1.b2应用，如下图所示：
与访问www.a1.a2不同的是我们在重定向到SSO Authorization时已经不需要再去输入用户名，因为sso.s1.s2此时已经存有cookie，直接用cookie验证。
以上，就是一个简单的基于Cookie的登陆系统。
对于第一个问题，一般可以采用类似与memcached的分布式缓存的方案，既能提供可扩展数据量的机制，也能提供高效访问
对于第二个问题，一般采取数字签名的方法，要么通过数字证书签名，要么通过像md5的方式，这就需要SSO系统返回免登URL的时候对需验证的参数进行 md5加密，并带上token一起返回，最后需免登的系统进行验证信任关系的时候，需把这个token传给SSO系统，SSO系统通过对token的验证 就可以辨别信息是否被改过
对于最后一个问题，可以通过白名单来处理，说简单点只有在白名单上的系统才能请求生产信任关系，同理只有在白名单上的系统才能被免登录。
转载地址：http://www.jianshu.com/p/baa94d5f1673
