单点登录是我最喜欢的技术解决方案，一方面可以提高产品的易用性，另一方面可以隔离各种APP应用所需的登录服务，对性能和工作量都有好处。 上次，我们研究了JWT如何应用于会话管理。 此外，由于在以前的项目中也使用了CAS这一比较受欢迎的单点登录框架，因此我们正在考虑如何与JWT的单点登录一起使用。 我希望尽可能地将这两种技术的好处合并到项目中。 介绍从CAS考虑的SSO的实现方案。
**
前言*
其实CAS这个方案很好，非常强大，其最新版本已经集成到JWT中，如果不想自己开发单点登录的服务，完全可以考虑使用CAS。 但是，我认为我们做项目的时候，一开始可能不需要那么强大的产品。 CAS提供的登录格式很多，但我们只需要应用其中之一。 而且，这个框架正因为强大，所以很复杂，很容易得到。 但是，如果遇到想向CAS添加微信登录等特殊需求，就需要深入了解其原理和API。 综合考虑，还是明确CAS的原理，自己实现基本的SSO服务比较放心。
本文的内容需要对JWT和SSO有基本的理解。 从这两篇文章中可以知道JWT的用途。 三种web会话管理方法JWT提供了基于token的会话管理，并且可以从以下资料中了解SSO的内容： SSO_百度百科。
**
方案介绍*
本文主要通过时序图的方式介绍JWT SSO的实现原理。 虽然还没有具体的技术实现，但如果草莓充分理解这个方案的原理，我认为最终的实现并不复杂，可以用任意的平台语言来实现。 以下时间图模拟了CAS、系统a和系统b这三个服务，分别部署在cas.com、systemA.com和systemB.com上。 CAS服务用于管理SSO会话； 系统a和系统b表示实际的业务系统。 从5个场景分别说明实现该SSO方案的详细情况。 先看看第一个吧。
场景1 :用户开始第一次访问业务系统，他首先访问的是系统a上的some/page页面，最后成功访问该页面的过程，在这个过程中，理解的关键应该是
为了完成会话的创建和会话的传输，我们使用了两个cookie(jwt和sid )和三次重定向。 因为JT的cookie写在名为systemA.com的域下，所以每次重定向到systemA.com时，只要有名为jwt的cookie，就有历史sid的cookie写在名为cas.com的域下验证名为sid的cookie jwt时，我如何知道当前用户创建了sso的会话？ 由于在jwt的payload中存储了之前创建的sso会话的session id，因此cas取得jwt后，就取得了session id，用该session id判断有无对应的session对象即可。 此外，由于CAS服务中的session是服务端创建的对象，因此如果CAS采用群集部署，还必须考虑session id的唯一性和session的共享。 session id的唯一性是用用户名密码加上随机数，而session共享(如md5 )可以通过支持集群部署的专用缓存服务器管理session轻松处理服务端session具有生命周期的特点，到期后需要自动销毁，所以为了不引起其他问题，不要自己写session的管理，在github上查找开源缓存管理中间件进行处理即可存储session对象时，可以将session id作为key，将session对象本身作为value存储在缓存中。 session对象可以存储session id和登录后获取的用户信息等业务数据，便于在业务系统调用时从session返回会话数据。
场景2 :用户登录后，继续访问系统a中的其他页面，如some/page2。 其处理步骤如下。
从这一步骤可以看出，即使在登录后，也必须每次检查jwt的有效性和会话的有效性。 实际上，jwt的有效性也可以放入业务系统中进行处理，但会话的有效性必须到CAS端。 CAS在获取jwt中的会话id后，访问会话缓存服务器以验证是否存在与该会话id对应的会话对象，如果不存在，则表明会话已销毁(终止)
方案3 )用户登录系统a后，访问系统b中其他系统的资源，如some/page。 最终可以访问系统b中的some/page的过程如下：
此过程的关键是在第一次重定向时将名为sid的cookie带回CAS服务器。 因此，CAS服务器可以确定会话是否已建立，如果已建立，则可以跳过登录页逻辑。
场景4 )用户继续访问系统b的其它资源，例如系统b的some/page2。
这个场景的逻辑与场景2完全一致。
场景5 :结束登录。 从系统b退出后，最终进程如下。
最重要的是清除sid的饼干。 jwt的cookie可能已创建业务系统，因此退出时无法逐个清除这些系统的cookie。 清除sid后，即使这些jwt的cookie在下次访问时传递给业务系统
的服务端，由于jwt里面的sid已经无效，所以最后还是会被重定向到CAS登录页进行处理。 方案总结以上方案两个关键的前提：
整个会话管理其实还是基于服务端的session来做的，只不过这个session只存在于CAS服务里面；
CAS之所以信任业务系统的jwt，是因为这个jwt是CAS签发的，理论上只要认证通过，就可以认为这个jwt是合法的。
jwt本身是不可伪造，不可篡改的，但是不代表非法用户冒充正常用法发起请求，所以常规的几个安全策略在实际项目中都应该使用：
使用https
使用http-only的cookie，针对sid和jwt
管理好密钥
防范CSRF攻击。
尤其是CSRF攻击形式，很多都是钻代码的漏洞发生的，所以一旦出现CSRF漏洞，并且被人利用，那么别人就能用获得的jwt，冒充正常用户访问所有业务系统，这个安全问题的后果还是很严重的。考虑到这一点，为了在即使有漏洞的情况将损害减至最小，可以在jwt里面加入一个系统标识，添加一个验证，只有传过来的jwt内的系统标识与发起jwt验证请求的服务一致的情况下，才允许验证通过。这样的话，一个非法用户拿到某个系统的jwt，就不能用来访问其它业务系统了。
在业务系统跟CAS发起attach/validate请求的时候，也可以在CAS端做些处理，因为这个请求，在一次SSO过程中，一个系统只应该发一次，所以只要之前已经给这个系统签发过jwt了，那么后续 同一系统的attach/validate请求都可以忽略掉。
总的来说，这个方案的好处有：
完全分布式，跨平台，CAS以及业务系统均可采用不同的语言来开发；
业务系统如系统A和系统B，可实现服务端无状态
假如是自己来实现，那么可以轻易的在CAS里面集成用户注册服务以及第三方登录服务，如微信登录等。
它的缺陷是：
第一次登录某个系统，需要三次重定向（不过可以优化成两次）；
登录后的后续请求，每次都需要跟CAS进行会话验证，所以CAS的性能负载会比较大
登陆后的后续请求，每次都跟CAS交互，也会增加请求响应时间，影响用户体验。
你可以从下面这个资料了解CAS的单点登录实现过程：
https://apereo.github.io/cas/4.1.x/protocol/CAS-Protocol.html