敞开成长之旅！这是我参与「日新计划 2 月更文应战」的第 1 天，点击查看活动详情
咱们好，我是车辙。之前咱们经过面试的形式，讲了JWT完成单点登录(SSO)的规划思路，而且到最终也留下了疑问，什么是CAS。
没看过的同学建议点击下方链接先看下，两者仍是有必定连贯性的。
传送门：面试系列：4000字长文，让你了解单点登录（一）
问寒问暖开始
今天是上班的第一天，刚进公司就见到了前次的面试官，穿着格子衬衫和拖鞋，咱们就叫他老余吧。老余看见我就开始勾肩搭背聊起来了，彻底便是自来熟的样子，和我最近看的少年歌行里的某人很像。
什么是CAS呢
老余：前次你说到了CAS，你觉得CAS是什么?
我：之前咱们面试的时候，我讲了JWT单点登录带来的问题，然后慢慢优化，最终衍变成了中心化单点登录体系，也便是CAS的计划。
CAS（Central Authentication Service），中心认证服务，便是单点登录的某种完成计划。你能够把它了解为它是一个登录中转站，经过SSO站点，既解决了Cookie跨域的问题，一起还经过SSO服务端完成了登录验证的中心化。
这儿的SSO指的是：SSO体系
它的规划流程是怎样的
老余：你能不能讲下它的大致完成思路，这说的也太虚头巴脑了，简直是听君一席话，如听一席话。
我：你别急呀，先看下它的官方流程图。
重定向到SSO
首要，用户想要拜访体系A的页面1，自然会调用www.chezhe1.com的约束接口，（比如说用户信息等接口登录后才能拜访）。
接下来 体系A 服务端一般会在拦截器【也可所以过滤器，AOP 啥的】中依据Cookie中的SessionId判别用户是否已登录。假如未登录，则重定向到SSO体系的登录页面，而且带上自己的回调地址，便于用户在SSO体系登录成功后返回。此刻回调地址是：www.sso.com?url=www.chezhe1.com。
这个回调地址咱们应该都不会陌生吧，像那种异步接口或者微信授权、付出都会涉及到这块内容。不是很了解的下面会解释~
另外这个回调地址还必须是前端页面地址，主要用于回调后和当前体系树立会话。
此刻如下图所示：
用户登录
- 在重定向到
SSO登录页后，需求在页面加载时调用接口，依据SessionId判别当前用户在SSO体系下是否已登录。【注意这时候现已在 SSO 体系的域名下了，也就意味着此刻Cookie中的domain现已变成了sso.com】
为什么又要判别是否登录？由于在 CAS 这个计划中，只要在SSO体系中为登录状况才能标明用户已登录。
- 假如未登录，展现账号密码框，让用户输入后进行
SSO体系的登录。登录成功后，SSO页面和SSO服务端树立起了会话。 此刻流程图如下所示：
安全验证
老余：你这儿有一个很大的漏洞你发现没有？
我：emm，我当然知道。
关于中心化体系，咱们一般会分发对应的AppId，然后要求每个应用设置白名单域名。所以在这儿咱们还得验证AppId的有效性，白名单域名和回调地址域名是否匹配。否则有些人在回调地址上写个黄色网站那不是凉凉。
获取用户信息登录
- 在正常的体系中用户登录后，一般需求跳转到事务界面。可是在
SSO体系登录后，需求跳转到原先的体系A，这个体系A地址怎样来？还记住重定向到SSO页面时带的回调地址吗？
经过这个回调地址，咱们就能很轻易的在用户登录成功后，返回到原先的事务体系。
- 所以用户登录成功后依据回调地址，带上
ticket，重定向回体系A，重定向地址为：www.chezhe1.com?ticket=123456a。 - 接着依据
ticket，从SSO服务端中获取Token。在此过程中，需求对ticket进行验证。 - 依据
token从SSO服务端中获取用户信息。在此过程中，需求对token进行验证。 - 获取用户信息后进行登录，至此体系A页面和体系A服务端树立起了会话，登录成功。
此刻流程图如下所示：
别以为这么快就结束了哦，我这边提出几个问题，只要把这些想了解了，才算是真的清楚了。
- 为什么需求 Ticket?
- 验证 Ticket 需求验证哪些内容？
- 为什么需求 Token?
- 验证 Token 需求验证哪些内容？
- 假如没有Token，我直接经过Ticket 获取用户信息是否可行？
为什么需求 Ticket
咱们能够反着想，假如没有Ticket，咱们该用哪种方法获取Token或者说用户信息？你又该怎样证明你现已登录成功？用Cookie吗，显着是不行的。
所以说，Ticket是一个凭证，是当前用户登录成功后的产品。没了它，你证明不了你自己。
验证 Ticket 需求验证哪些内容
- 签名：关于这种中心化体系，为了安全，绝大数接口请求都会有着验签机制，也便是验证这个数据是否被篡改。至于验签的具体完成，形形色色都有。
- 实在性：验签成功后拿到
Ticket，需求验证Ticket是否是实在存在的，不能说随意造一个我就给你返回Token吧。 - 运用次数：为了安全性，
Ticket只能运用一次，否则就报错，由于Ticket许多情况下是拼接在URL上的，肉眼可见。 - 有效期：另外则是
Ticket的时效，超过必定时刻内，这个Ticket会过期。比如微信授权的Code只要5分钟的有效期。 - ……
为什么需求 Token?
只要经过Token咱们才能从SSO体系中获取用户信息，可是为什么需求Token呢？我直接经过Ticket获取用户信息不行吗？
答案当然是不行的，首要为了确保安全性，Ticket只能运用一次，另外Ticket具有时效性。但这与某些体系的事务存在必定冲突。因此经过运用Token增加有效时刻，一起确保重复运用。
验证 Token 需求验证哪些内容？
和验证 Ticket类似
- 签名 2. 实在性 3. 有效期
假如没有 Token，我直接经过 Ticket 获取用户信息是否可行？
这个内容其实上面现已给出答案了，从完成上是可行的，从规划上不应该，由于Ticket和Token的职责不相同，Ticket 是登录成功的票据，Token是获取用户信息的票据。
用户登录体系B流程
老余：体系A登录成功后，那体系B的流程呢？
我：那就更简单了。
比如说此刻用户想要拜访体系B，www.chezhe2.com的约束接口，体系B服务端一般会在拦截器【也可所以过滤器，AOP 啥的】中依据Cookie中的SessionId判别用户是否已登录。此刻在体系B中该体系必定未登录，所以重定向到SSO体系的登录页面，而且带上自己的回调地址，便于用户在SSO体系登录成功后返回。回调地址是：www.sso.com?url=www.chezhe2.com。
咱们知道之前SSO页面现已与SSO服务端树立了会话，而且由于Cookie在SSO这个域名下是同享的，所以此刻SSO体系会判别当前用户已登录。然后便是之前的那一套逻辑了。
此刻流程图如下所示：
技能以外的事
老余：不错不错，了解的还能够。你发现这套体系里，做的最多的是什么，有什么技能之外的感悟没。说到这，老余叹了口气。
我：我懂，做的最多的便是验证了，验证实在性、有效性、白名单这些。明明一件很简单的事，最终搞的那么杂乱。像现在银行里取钱相同，各种条条框框的约束。我有时候会在想，技能发展、思想革新关于人类文明毋庸置疑是有益的，可是关于咱们人类真的是一件功德吗？假如咱们人类全是机器人那样的思想是不是会更好点？
老余：我就随意一提，你咋巴拉巴拉了这么多。我只清楚一点，拥有七情六欲的人总是好过没有情感的机器人的。好了，干活去吧。
总结
这一篇内容就到这了，咱们聊了下关于单点登录的 CAS 规划思路，其实CAS 往大了讲还能讲许多，惋惜我的技能储备还不行，今后有机会补充。假如想了解的更深刻，也能够去看下微信授权流程，应该会有协助。
最终还趁便提了点技能之外的事，记住有句话叫做：科学的止境是哲学，我好像开始慢慢了解这句话的意思了。
假如这篇文章对您有所协助，能够重视我的大众号《车辙的编程学习圈》，也能够在我的博客网站扫码重视我的博客网站。
我是车辙，小册《SkyWalking》作者，一名常被HR戏弄为XX杨洋的互联网打工人
