php 单点登录基础知识概要
当你知道自己要去哪里的时候，全世界都在为你添堵。
单点登录（Single Sign On），简称为 SSO，意思是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的其它应用系统。一般常用于同一家公司的不同子系统之间的登录认证。
单点登录方式有2种：
1、基于 Cookie 凭证
这种方式适用于子系统之间主域名一致，因为只有这样才能让不同子系统之间共享 Cookie
设置cookie 在子域名的cookie也可以直接访问主域名，这样就实现了不同域名之间的共享
注意：基于 Cookie 实现的基于 Session 的单点登录有其局限性，那就是不同系统之间主域名需要一致，否则不能生效
2、通过 CAS 实现 SSO 系统
这种方案适用于所有场景，只是相比较 Cookie 凭证来说理解和实现起来更复杂一些。、
CAS（Central Authentication Service）是耶鲁大学的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方案。采用 CAS 最大的因素是从安全性角度来考虑，用户在 CAS 服务端录入用户名和密码之后通过 Ticket 在不同系统间进行认证，不会在网上传输密码，从而保证安全性。
CAS具有以下特点：
- 开源通用的企业级单点登录解决方案；
- 一个 CAS Server，多个 CAS Client（需要认证的 Web 应用）。
- CAS Client 支持非常多的客户端，包括 Java、.Net、PHP、Ruby 等。
CAS单点登录的原理
典型的 CAS 单点登录实现方案涉及至少三个方面：CAS Server、CAS Client（需要认证的 Web 应用）、客户端浏览器。
流程：
首先，用户在客户端浏览器访问 Web 应用（姑且称之为应用 A），发起登录请求，Web 应用 A 会将认证请求重定向到 CAS Server，同时在客户端写入一个 Cookie，
· 其次，CAS Server 会验证用户是否已经认证，如果没有认证会进行认证操作（一般通过数据库进行匹配），同时生成一个 Ticket（保存起来留待后续验证时用）；
然后， CAS Server 会通过带有 Ticket 的回调地址重定向回 Web 应用 A，此时 Web 应用 A 还不知道用户是否已经认证，会再次通过这个 Ticket 去 CAS Server 进行校验，如果校验通过，则从服务端删除该 Ticket，并返回认证用户信息给 Web 应用 A，Web 应用 A 根据用户信息及一开始写入的 Cookie 设置 Session，至此，用户在 Web 应用 A 中完成登录认证。
注：需要注意的是这个 Ticket 是一次性的，是与指定用户与服务相关联的，用过一次就废弃了。
如果还有另一个 Web 应用（将其称之为应用 B）此时也发起了登录请求，同样会将认证请求重定向到 CAS Server，同时在客户端写入一个 Cookie，此时用户在 CAS Server 已经处于登录状态（如果退出还需要重新登录），但是是不同应用发起的认证服务，所以，会重新生成一个 Tikcet，然后重定向回这个 Web 应用 B，同上面应用 A 的认证逻辑一样，这个 Web 应用 B 也会通过这个 Ticket 去 CAS Server 验证认证状态，验证成功后废弃该 Ticket，将用户信息返回给 Web 应用 B，应用 B 基于用户信息和一开始写入的 Cookie 设置 Session，这样 Web 应用 B 也完成单点登录。
由此可见，其实真正的登录操作是在 CAS Server（登录中心）实现的，客户端 Web 应用 A、B 都是通过 Ticket 进行登录状态验证，验证通过后各自设置 Session 完成各自系统的认证，从而实现单点登录，这个单点就是 CAS Server。
当用户退出的时候，比如从 Web 应用 A 发起退出请求，会在 A 系统先退出，然后将告知 CAS Server 用户退出，这样，CAS Server 会在服务端（登录中心）将该用户退出，并且将退出消息告知其它子系统，其它子系统再各自完成退出操作，从而完成了所有系统的用户退出操作。
整个过程中，子系统与 CAS 服务端之间的交互均采用 SSL 协议（HTTPS），从而保证数据传输的安全性。
CAS单点登录退出
原理概述基于 CAS 单点登录系统的退出主要包含两个部分。
- CAS 客户端应用的退出
- CAS 服务端退出登录状态
我们在 CAS 客户端应用退出后将页面重定向到服务端退出登录状态，然后通过传递过去的回跳地址跳转回客户端应用退出后跳转页面。当然，此时通过单点登录的其它客户端系统还是处于登录状态的，需要等到对应 Session 过期后才能退出，因为我们使用的 CAS 扩展包是基于 PHP 自带的 Session 实现的登录操作，生成的用于存储 Session ID 的 Cookie 完全是随机的，跟指定用户没有任何关联，所以无法通过后端代码实现指定用户前端 Cookie 和后端 Session 的清空。
