传统方式及弊端
将 userinfo 写入Cookie，首先不安全，最重要的是 无法跨域 （cookie是和域绑定的）。CAS协议就是为实现单点登录而诞生的。
CAS协议原理
Yale 大学发起的一个开源项目（基于Java）
CAS Server 为独立部署的 Web 应用
CAS Client 支持多种客户端
概念解释
单点登录（Single sign-on, SSO）：在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
统一用户：多个应用共用一套帐号体系，统一用户是 单点登录 的实现前提。一般，储存用户的公有属性在中央认证服务器。
局部会话（Application Session）：业务系统服务器（豆瓣读书、电影等服务器）与 浏览器 的会话。
全局会话（CAS Session）：CAS认证服务器（用户中心）与 浏览器 的会话。
Service：业务系统的路由，提前在 CAS认证服务器注册过。
Ticket Granted Ticket — TGT：大令牌，记录某用户全局会话的状态。
CASTGC — TGC：Ticket Granting Cookie，TGT记录在Cookie中的内容，一般是TGT的id。
Service Ticket— ST：小令牌，用来向CAS认证服务器（用户中心）兑换用户信息。一般，限制使用次数或有效期。
组成部分
CAS Server：主要负责对用户的认证工作。（用户中心）
CAS Client ：负责处理对客户端受保护资源的访问请求，登录时，重定向到 CAS Server。（各业务系统，豆瓣读书、电影等）
基本流程
A 访问服务：用户浏览器请求访问 业务系统（读书、电影等）。
B 定向认证：业务系统 引导浏览器 重定向 到CAS认证服务器（用户中心）。
C 用户登录：用户在 用户中心 完成登录，全局会话记录此次登陆。
D 发放票据：CAS服务器产生Service Ticket，并 重定向 到业务系统。
E 兑换信息：业务系统用Service Ticket 向CAS服务器 兑换用户信息。
CAS协议的具体流程及细节
建立单点登录，首次访问豆瓣
A: 浏览器请求访问 豆瓣读书。
B: 豆瓣读书 引导浏览器 重定向 到 豆瓣用户中心。
携带 Service参数
C: 在用户中心完成登录，建立全局会话。
验证Service
生成TGT-在浏览器记录CASTGC，即TGT.id，即 建立全局会话D: CAS服务器产生Service Ticket，并 重定向 到业务系统。
用TGT 签发 ST
重定向到 Service代表的 豆瓣读书 路由,并携带 ST
E: 豆瓣读书 用Service Ticket 向 用户中心服务器 兑换用户信息。
豆瓣读书服务器获取 ST
豆瓣读书在后台用 ST 向 用户中心服务器 兑换用户信息，官方使用xml传输信息（本文用JSON代替）
兑换成功后，豆瓣读书 用Session或Cookie 记录用户的登录状态，即 建立局部会话。
第二次访问豆瓣读书
A: 请求携带Session，豆瓣读书判断局部会话有效，即完成登录。首次访问豆瓣电影与首次访问豆瓣读书的流程一样
B: 豆瓣用户中心服务器 验证TGT，判断 全局会话是否存在。请求携带存有CASTGC的Cookie（服务端的域下面）
用CASTGC验证TGT，通过后，即可完成用户登录，接着签发ST
以上只是单点登录的流程，完整的单点登录还应该支持单点登出（Single Logout, SLO）
单点登出（SLO）
CAS项目及协议支持单点登出，但是并未给出详细的流程图，作者是根据CAS2.x与CAS3.x的指南文档进行归纳总结得出结论。
A: 浏览器请求 豆瓣读书的 /logout，豆瓣读书 删除Session相关内容，即清除局部会话。
B: 豆瓣读书 引导浏览器重定向到 用户中心的 /logout，携带Cookie中的CASTGC
C: 清除全局会话，删除 Cookie中的CASTGC，注销 TGC对应的TGT
D: 认证服务器 通知所有已登录的业务系统清除局部会话，找到TGT签发的ST，即所有已登录的业务系统（豆瓣电影、音乐），在后台，通知 所有有关的业务系统（Fire & Forget），携带ST
E: 业务系统 接到通知后 清除局部会话，用ST 清除 对应的Session，即 清除对应的局部会话
数据库
CAS认证服务器
User：用户表username：用户名
password：密码
Service：业务系统的服务接入表
url：Service的业务路由
logout_url：Service的退出路由
TGT：大令牌表
tgt：ticket_granted_ticket, 大令牌
user_id：User.id
expires_in：过期时间
validate：是否有效(-1：无效，1：有效)
ST：小令牌表
st：service_ticket, 小令牌
user_id：User.id
tgt_id：TGT.id，由哪个TGT签发
service_id：Service.id
used：使用次数，一般限制使用次数
expires_in：过期时间
validate：是否有效(-1：无效，1：有效)
Client服务器
Info：信息表，代表该服务器的用户资源
username：用户名
info：资源
ST：小令牌表，业务系统记录ST的状态，用于根据ST删除对应的Session
st：service_ticket, 小令牌
validate：是否有效(-1：无效，1：有效)
关键点与扩展
CAS认证服务器需要验证Service的有效性（提前注册），避免被攻击。
TGT只是代表用户登录，不对应Service。而ST对应Service。
SLO，业务系统收到CAS认证服务器通知后，根据ST来删除对应的Session，本文只是在 Client数据库 注销了对应的ST。因为，每次登陆时，会验证ST有效性。
SLO的业务系统可以根据具体业务需要不支持清除局部会话，比如邮件等业务。
Flask的原生session机制是存储在浏览器，而不是通常session存储在服务器，可以利用flask_session重构session存储机制，或 定制flask的session模块代码。