前后端分离怎么用cas单点登录？基于JWT和CAS的SSO单点登录方案

前后端分离怎么用cas单点登录？基于JWT和CAS的SSO单点登录方案首次访问系统A的请求流程当用户对业务系统A的页面page01发起第一次请求时，请求流程如下图所示。根据CAS协议，整个系统分为CAS Server和CAS Client两个角色，CAS Server负责完成对用户的认证工作；CAS Client 与受保护的应用部署在一起。JWT标准是应用最为广泛的基于Token的会话管理方案，前文《Java面试常见问题：JWT是什么？》曾经介绍过JWT标准。CAS方案也支持JWT，本文我们来介绍一下基于JWT和CAS的SSO单点登录方案。假设业务系统A和业务系统B都依赖CAS认证服务提供单点登录的会话管理。CAS提供单点登录

单点登录是一种比较流行的服务于企业业务整合的一种解决方案。单点登录（SSO：Single Sign On）的意思是：在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。比如我们登录淘宝网后，再打开天猫首页可以发现已经是登录状态了。

SSO 这个概念已经出现很久，目前已有很多非常成熟的实现方案，比如Opensso，OpenAM，Kerberos，CAS等。其中CAS方案在Java Web领域应用最为广泛。

• OpenSSO：曾经Sun的一款开源SSO产品，后来Sun被Oracle收购以后，Oracle便关闭了OpenSSO这个项目。
• OpenAM：OpenAM的原型就是OpenSSO，可用于替换被取消的OpenSSO。
• Kerberos：麻省理工研发的一个基于DES加密技术的网络认证协议。Windows2000和后续的微软操作系统都将Kerberos作为默认认证方法。
• CAS：CAS（Central Authentication Service）是耶鲁大学发起的一个开源项目，支持Java .Net PHP等各种语言开发的web应用。

要实现单点登录，通常需要有一个专门的SSO认证中心，在访问业务系统的资源前，用户需要先在认证中心认证身份，才能获得允许访问业务系统的令牌（token）。

SSO基本原理

根据CAS协议，整个系统分为CAS Server和CAS Client两个角色，CAS Server负责完成对用户的认证工作；CAS Client 与受保护的应用部署在一起。

JWT标准是应用最为广泛的基于Token的会话管理方案，前文《Java面试常见问题：JWT是什么？》曾经介绍过JWT标准。CAS方案也支持JWT，本文我们来介绍一下基于JWT和CAS的SSO单点登录方案。假设业务系统A和业务系统B都依赖CAS认证服务提供单点登录的会话管理。

CAS提供单点登录

SSO登录过程

当用户对业务系统A的页面page01发起第一次请求时，请求流程如下图所示。

首次访问系统A的请求流程

（1）访问系统A触发CAS认证。浏览器请求 GET http://systemA.com/page01，系统A发现未登录，通知浏览器重定向到CAS，返回302 Location:http://cas.com/login?redirectUrl=http://systemA.com/page01

（2）CAS返回登录表单。浏览器请求 GET http://cas.com/login?redirectUrl=http://systemA.com/page01，此时CAS还未创建单点登录的Session，返回登录页给浏览器，等待用户输入用户名和密码。

（3）CAS为系统A签发jwt。浏览器提交表单到CAS，发送请求 POST http://cas.com/login?redirectUrl=http://systemA.com/page01。此时CAS要做3件事情：

1. CAS根据POST提交的表达验证用户名和密码，如果验证通过，就创建一个SSO Session对象，并将session id写入cookie中。
2. CAS为系统A签发一个jwt，在payload中指定过期时间，以及SSO会话的session id。
3. 通知浏览器重定向到系统A的 /cas/attach 接口，并把jwt返回浏览器，返回302 Location: http://systemA.com/cas/ attach?jwt=x.y.z&redirectUrl= http://systemA.com/page01

（4）请求资源验证jwt。浏览器请求系统A，GET http://systemA.com/cas/ attach?jwt=x.y.z&redirectUrl= http://systemA.com/page01。系统A从请求中取得CAS签发的jwt，并跟CAS验证jwt是否有效。如果CAS验证通过，系统A将jwt存入cookie，并通知浏览器重定向到原来要访问的page01页面。

（5）返回页面。浏览器请求 GET http://systemA.com/page01，系统A的cookie已经存在jwt，再次通过CAS来验证jwt是否有效。CAS验证通过，返回sso session中的数据给系统A。系统A处理对page01的请求，并返回页面给浏览器。

单点登录以后

当浏览器请求系统A的另外一个页面page02时，请求过程与上面第（5）步基本一致。

登录以后访问系统A的流程

当浏览器请求另外一个系统B，流程如下。

单点登录后访问另外的系统B

（1）浏览器访问系统B，系统B发现没有jwt，则通知浏览器跳转CAS，返回302 Location:http://cas.com/login?redirectUrl=http://systemB.com/page01

（2）浏览器访问CAS，cookie中附带session id。此时CAS发现已创建sso session，并验证有效性。如果验证通过，则为系统B签发jwt，在payload中指定过期时间以及SSO会话的session id。

（3）浏览器访问系统B的/cas/attach接口，系统B取得jwt后向CAS验证。如果验证通过，则系统B在cookie中存入jwt，并通知浏览器重定向到本来要访问的页面。

（4）浏览器访问http://systemB.com/page01 此时系统B的cookie中已经存在CAS签发的jwt，系统B向CAS验证，验证通过后，CAS向系统B返回sso session数据。最后系统B返回页面给浏览器。

在访问系统B的过程中，已经不需要用户重新在登录页面中输入用户名和密码，实现了单点登录。

当浏览器在系统B退出登录。

退出登录

浏览器访问系统B的/cas/logout接口，重定向到CAS。CAS要销毁sso session对象，并清除session id的cookie。

此时jwt的cookie在系统A和系统B中还存在，不需要挨个去删除。即使jwt在下次访问时会随着cookie再传到服务端，但因为session id已经失效了，最终还是会重定向到CAS的登录页。所以不需要去删除各个业务系统的jwt的cookie。

总结

整个单点登录的会话管理是基于CAS服务的session来实现的。对业务系统的资源请求，都会携带CAS签发的jwt。只要CAS认证通过，那么业务系统就可以放心允许客户端请求资源。

总的来说，这个方案的好处有：

1. 完全分布式，跨平台，CAS以及业务系统均可采用不同的语言来开发；
2. 业务系统不需要保存登录状态，可实现服务端无状态
3. 比较容易在CAS里集成第三方登录服务，如微信登录。

不过这个方案也有一些缺陷：

1. 第一次登录系统时，需要三次重定向；
2. 登录后的后续请求，每次都需要跟CAS进行会话验证，CAS的压力会比较大，也会增加请求响应时间，影响用户体验。

我会持续更新关于物联网、云原生以及数字科技方面的文章，用简单的语言描述复杂的技术，也会偶尔发表一下对IT产业的看法，请大家多多关注，欢迎留言和转发，希望与大家互动交流，谢谢。