SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
单web系统中，客户端与服务器仅建立单一会话，只需要登录成功后写入Cookie，每次请求都携带该Cookie，服务器端只验证Cookie是否有效，即可判断是否登录。
随着业务增长出现了其他应用系统，每个系统只维持自己的会话会出现如下问题：
所以需要将公共模块抽象出来，组成一个通用的认证系统，承担起所有业务系统的登录认证功能，也即SSO系统（Single Sign On）。
抽象出认证系统之后，单点登录系统需要完成两个主要工作，全局会话的保持和局部会话的保持。客户端与业务系统之间是局部会话，与SSO系统之间是全局会话。SSO系统分为两部分，SSO服务端和SSO客户端，服务端则SSO认证系统，客户端将集成进入业务系统，负责局部会话的新增、删除、验证。
CAS的整体架构分为客户端和服务端。客户端支持多种服务器应用，同时也支持多语言，包括GO、Python、PHP、Java可以看到对市面上的主要语言都有支持。
服务端的技术实现，首先是Spring MVC+Spring Web Flow，Web Flow主要用于将组件串行执行，往下是票据组件、认证组件、认证组件支持的存储容器，可以是LDAP、数据库、活动目录，基本上的认证思路就是关系数据库结合Redis或Memcached来配合实现。
首次访问时，重定向到SSO服务端登录页，返回登录表单给浏览器，用户提交用户名密码，SSO服务端验证，成功后携带ticket重定向会SSO客户端，客户端与SSO验证ticket有效性，返回验证信息，SSO客户端写局部会话cookie，重定向回原地址，业务系统返回资源。
第二次访问该系统，会在该域名下存在上一步写的cookie，请求该系统时携带cookie，所有filter不会拦截该请求，直接返回资源。
在该系统域名下不存在局部会话，所以重定向到SSO服务端，SSO服务端会发现此客户端已经登录，所有生成ticket，客户端与SSO验证ticket有效性，返回验证信息，SSO客户端写局部会话cookie，重定向回原地址，业务系统返回资源。
淘宝的SSO系统是比较有新意的，除了校验登录状态模块，还加入同步登录状态模块，这样就让电商项目在SSO中变得很灵活。
在静态页中，会异步请求后台数据，这时候会被同步登录状态的SSO客户端filter拦截。如果需要同步登录状态，filter将重定向到login.taobao.jump接口，这个接口无论用户是否登录，都会重定向回SSO客户端的接口，在以下两个条件下发生跳转：
当用户请求到需要登录的数据资源时会被校验登录状态的filter拦截，出现以下两种情况：
如果SSO服务端登录成功，会携带token请求回SSO客户端，客户端验证token的filter拦截请求，与SSO服务端验证token有效性。如果通过，则返回用户基本信息、cookie 值等，所有的cookie值都是由SSO服务端发出的。
业务系统A：某个具体的业务系统，需要通过SSO系统实现登录，域名假定为localhost:6060
业务系统B：某个具体的业务系统，需要通过SSO系统实现登录，域名假定为localhost:7070
对于业务系统A或业务系统B都能够通过登录中心实现用户登录，并且用户只需要在A和B中的任意一个业务系统进行登录，另一个业务系统就能够自