到目前为止已经实现了一个基于session的SSO
优点：
1，安全 。所有的token的信息都是放在session里（客户端应用session、认证服务器session），在浏览器里只有一个jsessionId，在浏览器这边只要做好session固定攻击的防护，一般是不会有什么风险的。
2，可控性高。token信息存在了数据库，登录信息存在了redis，想让谁下线就让谁下线，想让谁失效就让谁失效。
3，跨域。客户端应用部署在哪个域名下，都可以直接跟认证服务器交互。
缺点：
1，复杂度高。 session和token机制混合使用，session又分为客户端服务器和认证服务器两种，各自有各自的过期时间，access_token和refresh_token 又都有各自的过期时间。你必须非常清楚每个东西是干嘛的，过期后对系统会产生什么影响，系统的行为是什么，你要怎么处理，都要心里很清楚，才能用好这种方案。
2，性能低。session、token的存取占用服务器资源，当用户量大的时候会有各种问题。比如当用户上亿的时候用这种方案是不可行的。
适用场景：
扫描二维码关注公众号，回复：
8465744 查看本文章
1，适用于百万以下用户。token表最多一百来万数据，这个性能是可以保证的，也不会占用服务器太多资源，也不用考虑分库分表、读写分离。
2，内部的管理系统。每一个客户端应用都是一个XX中心，如用户中心，订单中心，商品中心等，每一个中心都是可以单独部署的，他们都用同一个页面风格，各个系统可以跳来跳去，后边是一个统一的认证服务器，网关来访问微服务。用户看来是一个系统，适合于一定规模的内部管理系统。