前言
最近接手了一个新的项目，突然发现之前自己一直没有关注过公司的登陆鉴权方面的东西，就赶快打开文档搜索，发现了SSO这个东东，刚开始一脸懵，啥是SSO呀，后来搜索资料发现是Single Sign On的缩写，也就是单点登录，好奇的伙伴肯定会问，这个东西出现的目的是啥，这里用豆瓣举个例子，豆瓣的网页版有豆瓣图书，豆瓣电影这些，对于用户来说肯定不希望我登录了豆瓣图书，在访问豆瓣电影页面的时候依旧需要登录一遍吧，SSO就是为解决这类特定问题而提出的一种架构模式，在这种架构模式下，有CAS，OAuth2等具体实现方式，这篇文章主要是对CAS的流程进行一个详细的说明，在接下来的文章中会补充余下的比较流行的实现方式
知识补充
在正式介绍CAS的流程之前，我们首先需要思考在不知道SSO这种模式的情况下，我们该如何实现单点登录呢？
验证用户的登录态我们可以使用Cookie来做，而Cookie是不跨域的，这里衍生说一下例如一个网站的域名为www.jhd.com,另一个网站的域名为www.jhy.com，也就是在www.jhd.com下的Cookie的值与www.jhy.com是不共享的，但是有一个特例就是如果B域名是A域名的子域名，那么A域名下的Cookie对B域名是共享的，例如jhd.com和www.jhd.com，此时由于www.jhd.com是jhd.com的子域名，所以jhd.com的所有Cookie对于www.jhd.com来说是可见的
根据这个特性，可以想到，我们可以将Cookie信息统一绑定到所有子域名的父域名上，这样不就可以在各个子域名共享父域名登录的Cookie信息了吗？这当然是可以的，但是如果说当下的域名就是www.jhd.com和www.jhy.com，想实现在www.jhd.com登录之后，www.jhy.com不需要登录，这个方法就gg了
CAS协议详解
名词解释
CAS(Center Authentication Server)，本身是一个开源协议，这里讲解的主要是CAS协议在Web应用上的实践，对于非Web应用内容(代理模式)不作涉及
- TGT TGT就相当于CAS为用户设置一个登陆标识，如果在CAS端有用户的TGT信息，那么说明当前用户成功登陆过
- CASTGC 用户在CAS Server验证身份成功之后，CAS Server在返回的请求头中通过Set-Cookie设置CASTGC并在本地设置TGT，CASTGC的值对应了在CAS Server中保存的TGT的ID
- Ticket(ST) 当用户访问某个Service，Service发现用户没有ST，会让用户向CAS Server索要ST，CAS Server会判断用户带来的CSTGC的信息是否有对应的TGT，如果有的话，则为用户颁发ST，用户凭借这个ST再此访问Service时就可以成功访问了
流程讲解
先给小伙伴们上张图，这张图展示的是用户第一次访问www.jhd.com首页的整个流程，让小伙伴们对CAS的流程有一个整体宏观的认识:
(注: 对于上图中的service在实际过程中需要进行编码，这里为了让小伙伴们看的更清楚，就没有展示编码后的service哈)
用文字描述的话就是:
浏览器请求https://www.jhd.com，Web Server发现浏览器的Cookie中并没有携带登陆相关的信息，会重定向到CAS Server，CAS Server返回一个表单，让用户进行登陆，用户填写登陆信息之后，CAS Server进行用户信息验证，如果验证通过，则重定向到https://www.jhd.com，并携带两个信息，一个是CASTGC，一个是ST(ticket)，Web Server此时会通过ST以及(service = https://www.jhd.com)的值向CAS Server进行合法性验证，如果合法，CAS Server会返回给Web Server用户信息，此时Web Server将用户信息封装成token或其它用户标识字段放到Cookie中
那么当用户再次访问https://www.jhd.com的时候，是否还需要走CAS Server呢？ 答案是不需要，除非之前放到浏览器中的Cookie过期了
回到之前的问题，既然www.jhd.com可以通过CAS的机制实现登陆，那么CAS如何实现www.jhy.com无需登陆的逻辑呢？我们先来看张图:
从图中可以看出，当用户访问https://www.jhy.com的时候，Web Server没有获取到对应的Cookie信息，会先重定向到CAS Server，这次会多携带CASTGC的信息，CAS Server通过携带的CASTGC信息获取TGT，获取到了说明用户当前的登录态还是合法的，在返回的信息中夹带ST(ticket)，并重定向到https://jhy.com，此时Web Server会将Service信息以及ST发送到CAS Server进行验证，验证通过后得到用户信息，将用户信息封装为token或其它信息放到Cookie中返回，之后用户再次访问www.jhy.com，与上面说的处理机制相同
可以看到，通过CAS的这套机制，用户可以实现只需要登录一次，就可以访问所有CAS的信任域名🎉
安全问题 小伙伴们可能会问，CASTGC基于Cookie返回给浏览器，那如果Hacker获取到CASTGC的值，不就可以伪造请求了吗？这点我不反驳，但是CAS使用的是Seciruty Cookie，也就是使用https进行传输，所以可以截取到TGC的难度会非常大，另外需要注意的是ST是通过http传输的，所以为了更安全，ST每次只可以用一次，且有有效期，此外，ST会根据一套随机规则产生，以尽可能的保证ST的随机性，如果Hacker脑洞大开，在Web Server还未使用ST的时候搞了一个恶意请求，那就没办法了
结束语
对于CAS的内容先说到这，如果小伙伴们有自己的一些看法，或者我说的内容里面有些需要修正补充的地方，大家放到评论里面，和大家交流学习心得是一件幸福的事情，你们的反馈是我继续创作的最大动力！！
