单点登录SSO（Single Sign-On）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证
SSO的用途：
目前的企业应用环境中，往往有很多的应用系统，淘宝、天猫、爱淘宝等等产品和如办公自动化（OA）系统，财务管理系统，档案管理系统，信息查询系统等等。这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用SSO技术可以解决以上这些问题
SSO的好处：
方便用户：从用户实际使用角度考虑
用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。
方便管理员：从日常维护管理角度考虑
现在很多大的互联网公司都会有很多的应用，比如以下是淘宝网的截图：
天猫 聚划算 头条等都是不同的应用，有的甚至采用完全不同的域名，但是所有在淘宝注册的用户都是使用的一套用户名和口令，如果在这些系统直接切换做不到登陆状态的同 步，体验是非常差的。再举个栗子，很多公司内部系统也有很多个，比如HR系统，财务系统，考勤系统等等，如果员工在一个系统登陆了，跳转到另外一个系统还 需要登陆，就会让人很不爽...
基于此，SSO(Single Sign On)应运而生。当然，我们来现实这个需求的方法有很多种，使用Cookie是其中比较简单的方式，主要需要解决的问题是:Cookie是不能跨域传递的，如何将一个域的Cookie通知给其它应用(不在同一个域)？
so，如果你对cookie机制不太熟悉，请先google，并大致了解为什么cookie会设计成不能跨域等相关问题。
系统管理员只需要维护一套统一的用户账号，方便、简单。相比之下，系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号，不仅给管理上带来不方便，而且，也容易出现管理漏洞。
简化应用系统开发：从应用扩展角度考虑
开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统并不需要开发用户认证程序。
如何实现？
SSO有以下几种方式实现
共享Cookie
当我们的子系统都在一个父级域名下时，我们可以将Cookie种在父域下，这样浏览器同域名下的Cookie则可以共享，这样可以通过Cookie加解密的算法获取用户SessionID，从而实现SSO。
但是，后面我们发现这种方式有几种弊端：
a. 所有同域名的系统都能获取SessionID，易被修改且不安全；
b. 跨域无法使用。
ticket验证，我们目前采取的是这种方式
这种实现的SSO有以下几个步骤：
a. 用户访问某个子系统，发现如果未登录，则引导用户跳转到SSO登录页面；
b. 判断SSO是否已经登录；
c. 如果已经登录，直接跳转到回调地址，并返回认证ticket；
d. 如果未登录，用户正确输入用户名/密码，认证通过跳转到回调地址，并返回认证ticket；
e. 子系统获取ticket，调用SSO获取用户uid等信息，成功后让用户登录。
前面已经说了，如何通过Cookie来实现SSO，主要是如何解决跨域问题。首先来谈谈Set-Cookie中的domain属性。
Cookie domain
为了让Http协议在一定程度上保持上下文，server在响应的头部可以加入Set-Cookie来写入一些数据到客户端，Set-Cookie中的
domain字段用来表示这个cookie所在的域。
栗子：
我们访问，如果server在返回头部中加入了Set-Cookie,如果不指定domain,那么默认这个cookie的域就是，也就是只有访问时客户端才会把这个cookie返给服务端。
如果我们指定domain为.cookieexm.com，那么客户端在访问以下域名： www1.cookieexm.com a.cookieexm.com ***.cookieexm.com 时都能够把cookie返回。
所以，我们得出一条结论：客户端对cookie的domain的匹配是从结尾进行匹配的，有了这个基础，我们就可以实现我们的SSO登陆了。
cookie中需要注意的
设置为http-only
涉及登录凭证（如票据或者用户名）应该加密
cookie不能存放隐私数据
具体方案