单点登录SSO的实现方案及相关知识点总结
背景
将单体项目拆分为服务时，由于服务之间相互隔离，无法共享session，来获取登陆状态。如何实现一次登录，到处访问，这就是单点登录SSO要做的事。
实现方案
Redis共享session
将Session序列化到Redis，多个服务共享同一个Redis，直接读取Session。
以微服务为例：
① 用户请求网关，网关将请求转发到登陆服务，进行用户名密码校验，校验通过后将sessionId和用户id关联存到redis中，并返回登陆前请求的页面；
② 调用其他微服务时，网关服务从redis中获取sessionId关联的用户id，若存在则已登录，则允许调用，否则未登录，重定向到登陆页面。
存在问题：
跨域 :由于 Session ID 往往保存在浏览器 Cookie 中，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.cc.com 中登录后，Session ID 仅在浏览器访问 app1.cc.com 时才会自动在请求头中携带，而当浏览器访问 app2.cc.com 时，Session ID是不会被带过去的。此时将cookie的domain属性设置为父域名cc.com，path设置为根路径，那么子域都可以访问到。
这样的方式虽然实现简单，但无法跨主域访问。
Cookie共享Token
Token方式最大好处在于无需统一的验证服务器，是“多点验证模式”的主力实现技术。
各个服务器都通过统一的密钥对令牌进行加密解密，
该方式安全性高、稳定性好、性能消耗低，但必须保证各台应用服务器同域。
认证中心
部署认证中心，提供专门用于校验用户名密码的服务。SSO-Server使用Redis存储用户ticket，Spring拦截器过滤用户请求，验证用户的ticket，一致则放行，否则重定向。
Tip:ticket和cookie，都是验证信息的一种具体表现。cookie是具体指在网页上缓存的已经验证的信息，而ticket则可以以任何形式存在，包括cookie。
这样的方式相对复杂，支持跨域，扩展性好。
CAS就是经典的跨域SSO的实现。
基于token和基于session实现的比较
Session、Cokkie、Token区别
参考资料：
单点登录、SSO、CAS