SSO单点登录
SSO单点登录是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
实例
最初的时候，服务的提供者只做了一个单系统，所有的功能都在单系统上，此时不需要SSO，一次登录就可以访问所有功能，后来用户量越来越大且功能服务越来越多，为了合理利用资源和降低耦合性，服务商将功能划分为多个子系统，而子系统的用户登录凭证是相互隔离的，如果在这个子系统登录完成，再访问另一个子系统还需要登录，这显然不太合适，而SSO就是对于这种问题的解决方案，在多个系统中，用户只需要某一个系统中登录，在其他系统中都无需再次验证用户身份即可静默登录，例如在百度一次登录，再访问贴吧、网盘等都可以静默登录。
OAUTH与SSO区别
- 从信任角度来看，
OAUTH开放授权的服务端和第三方客户端不属于一个互相信任的应用群，而单点登录SSO的子系统都在一个互相信任的应用群，通常是同一个公司提供的服务。 - 从资源角度来看，
OAUTH开放授权主要是让用户自行决定在服务端的个人资源是否允许第三方应用访问，资源都在OAUTH服务提供者那一方，客户端是想索取用户的资源，而单点登录SSO的资源本身都在子系统这边，而不是在SSO服务器这一方，主要服务是用于登录，以及管理用户在各个子系统的权限信息。
实现方案
共享SESSION
如果系统是使用SESSION来记录用户信息的话，那么就可以采用共享SESSION的方式进行实现单点登录，使用SESSION信息作为单点登录的方式就需要解决两个问题，一是子系统的SESSION是相互隔离的问题，二是用户的SESSION-ID如何在客户端共享的问题。
SESSION的一致性的解决方案主要有SESSION同步、SESSION集中存储的方式，SESSION同步比较消耗资源，所以一般还是使用SESSION集中存储的方式。
对于SESSION-ID在客户端共享的问题，SESSION-ID主要还是存储在COOKIE中，所以需要解决的问题是COOKIE的跨域问题，对于同一个顶级域名下的二级域名，可以通过在SET-COOKIE时设置domain属性为顶级域名，即可实现在顶级域名与二级域名三级域名下的COOKIE共享，若是需要非子域名下的COOKIE共享，可以考虑使用P3P隐私参考项目平台Platform for Privacy Preferences的header的方式跨域SET-COOKIE。
Ticket
Ticket方式也称为SSO-Token，其是一个用户身份的标识，这个标识在所有子系统群中是唯一的，并且所有的子系统SERVER都可以验证这个Token并同时能够拿到这个Token所代表的用户信息，同样这种方式也需要解决COOKIE的跨域问题，同样一般也是需要使用顶级域名的domain属性或者P3P的header的跨域SET-COOKIE。
CAS
CAS中央认证服务Central Authentication Service，将认证服务单独抽出作为一个子系统，所有的登录认证服务都在CAS认证中心进行。CAS系统像是一个中转中心，可以认证所有用户的身份，同样也可以直接通过在CAS系统登录后以登录态跳转到其他各个系统。
假如我们存在三个子系统，A系统A.com、B系统B.com、认证服务SSO.com，当用户已经注册，登录时的主要流程：
- 用户打开系统
A，此时用户未登录，系统自动跳转到认证服务系统SSO.com并携带参数存储跳转地址A.com。 - 用户在
SSO.com输入账号密码，点击登录验证成功后，中央认证服务器返回一个Ticket，并将已经登录的COOKIE写入SSO.com认证服务的域名下，SSO.com认证服务重定向至跳转到认证服务时携带的地址，也就是上一步的A.com，并携带中央认证服务端下发的Ticket。 - 系统
A得到Ticket并向本系统的服务器传递Ticket，服务端验证Ticket无误后获取Ticket中携带的用户信息，并设置当前A系统的此用户为登录态，下发COOKIE信息等用户凭据，至此该用户可正常使用A系统的服务。 - 此时用户打开
B系统，由于用户未在B系统登录，系统自动跳转到认证服务系统SSO.com并携带参数存储跳转地址B.com。 - 用户在
SSO.com已经处于登录状态，此时直接从中央认证服务器获取Ticket，然后重定向至跳转到认证服务时携带的地址，也就是上一步的B.com，并携带中央认证服务端下发的Ticket。 - 系统
B得到Ticket并向本系统的服务器传递Ticket，服务端验证Ticket无误后获取Ticket中携带的用户信息，并设置当前B系统的此用户为登录态，下发COOKIE信息等用户凭据，至此该用户可正常使用B系统的服务。