参考文章（提前鸣谢）

我的师父把「JWT 令牌」玩到了极致

话说单点登录

什么是单点登录（SSO）

Spring Session解决Session共享

美团面试官：说说什么是单点登录？什么是SSO？什么是CAS？

微服务下实现单点登录（SSO）的几种方式

单点登录的三种方式

单点登录的实现原理-一叶知秋

单点登录(面试总结)

单点登录那些事儿（三）不同域下的单点登录

http认证鉴权05CAS和OAuth2区别

凭证

先了解一下用户登录的凭证存储模式。

我们都知道 HTTP 协议是一种无状态的传输协议，无状态表示对一个事务的处理没有上下文的记忆能力，每一个 HTTP 请求都是完全独立的。让服务端能够顺利区分出发送请求的用户是谁，来记录用户的信息，固然需要凭证。

关于凭证的存储方案，业界的安全架构中有两种方案：

Cookie-Session 模式
JWT 方案

Cookie-Session 模式

用户登录认证通过后，后端会存放该客户端的身份信息，也就是存放到 session 中，session 可以用来区分不同，然后返回一个 sessionId 给到客户端。

客户端将 sessionId 缓存在客户端。当客户端下次发送 HTTP 请求时，在 header 的 cookie 字段附带着 sessionId 发送给后端服务器。

后端服务器拿到 header 中的 sessionId，然后根据 sessionId 找到 session，如果 session 存在，则从 session 中解析出用户的身份信息，然后执行业务逻辑。

但是 Cookie-Seesion 模式却和 HTTP 无状态特性相悖，因为客户端访问资源时，是携带第一次拿到的 sessionId 的，让服务端能够顺利区分出发送请求的用户是谁。

所以，一般我们单系统实现登录会这样做：

登录：将用户信息保存在Session对象中
- 如果在Session对象中能查到，说明已经登录
- 如果在Session对象中查不到，说明没登录（或者已经退出了登录）
注销（退出登录）：从Session中删除用户的信息
记住我（关闭掉浏览器后，重新打开浏览器还能保持登录状态）：配合Cookie来用

Cookie-Session 模式的优势

状态信息都存储于服务器，只要依靠客户端的同源策略和 HTTPS 的传输层安全，保证 Cookie 中的键值不被窃取而出现被冒认身份的情况，就能完全规避掉上下文信息在传输过程中被泄漏和篡改的风险。Cookie-Session 方案的另一大优点是服务端有主动的状态管理能力，可根据自己的意愿随时修改、清除任意上下文信息，譬如很轻易就能实现强制某用户下线的这样功能。（来自凤凰架构）

Cookie-Session 模式的劣势

在单节点的单体服务中再适合不过，但是如果需要水平扩展要部署集群就很麻烦。

如果让 session 分配到不同的的节点上，不重复地保存着一部分用户的状态，用户的请求固定分配到对应的节点上，如果某个节点崩溃了，则里面的用户状态就会完全丢失。 _{根据请求的IP进行Hash映射到对应的机器上（这就相当于请求的IP一直会访问同一个服务器）}
如果让 session 复制到所有节点上，那么同步的成本又会很高。_{Tomcat集群Session全局复制（集群内每个tomcat的session完全同步）会影响集群的性能呢，不建议}
cookie-redis方案，spring-session就能做到（但还是只能限于同域下）

而为了解决分布式下的认证授权问题，并顺带解决少量状态的问题，就有了 JWT 令牌方案，但是 JWT 令牌和 Cookie-Session 并不是完全对等的解决方案，JWT 只能处理认证授权问题，且不能说 JWT 比 Cookie-Session 更加先进，也不可能全面取代 Cookie-Seesion 机制。

JWT方案

我们上面说到 Cookie-Session 机制在分布式环境下会遇到一致性和同步成本的问题，而且如果在多方系统中，则更不能将 Session 共享存放在多方系统的服务端中，即使服务端之间能共享数据，Cookie 也没有办法跨域( 无法跨顶级域名 )。

将整个系统的全局Cookie Domain设置于顶级域名上，这样SessionID就能在各个子系统间共享。

cookie能设置父级域名, a.xx.com b.xx.com , .xx.com域下的都能够持有同一份cookie，共享了cookie。（设置domain）

仍然有一定约束，跨顶级域名的情况完全无法处理。

转换思路，服务端不保存任何状态信息，由客户端来存储，每次发送请求时携带这个状态信息发给后端服务。原理图如下所示：

但是这种方式无法携带大量信息，而且有泄漏和篡改的安全风险。信息量大小受限没有比较好的解决方案，但是确保信息不被中间人篡改则可以借助 JWT 方案。JWT（JSON WEB TOKEN）是一种令牌格式，经常与 OAuth2.0 配合应用于分布式、多方系统的应用系统中。

jwt在项目中可以配合springsecurity做认证：

分布式情况下：

此处只是做个简单介绍，关于jwt详情可查看置顶的参考文章。

网上一些项目教程，基本要不token用cookie存，然后请求头携带；要不直接存LocalStorage、SessionStorage。

如果还想实现什么登录状态的管理，配合redis做管理也是行，但是这样好像上面用session共享也可以这样做，怪不得有人说这种做法使用jwt或者session其实大差不大。（看别的文章视频评论总结的）

在不同域下的单点登录还做不到（_{我们不能在自己的系统中给baidu.com的域设置Cookie}），看到部分文章会有提到淘宝登录后天猫也会登录，引出不同域下的单点登录问题。

一些文章基本没有说这些不同域下的问题，只简单提了上面的一些解决方案，就草草结束，下面对这个问题做一下笔记记录。

小结：

对于上面的问题，可以将单点登录大致总结为：

session广播机制实现
使用cookie+redis实现（spring-session…）
使用token（存cookie，localstorage…）

同域下的单点登录就实现了，但这还不是真正的单点登录。

疑惑

自己当时看一些文章的想法：上面的方法都能解决了挺多问题，为什么这样还说不上真正的单点登录呢，还有什么没有解决的么?

就算不同域下无法利用cookie，不可以token直接存LocalStorage么(_{网上那些项目都这样干了})，永久存就完事了，怎么就那么倔，硬是要用cookie。（可能过于暴力，不过它们也不会使用这种简单方案8，还是说cookie的特性很好，所以公司们都选择这样么，有大佬看到希望能回复一下）。

接下来还是继续记录CAS，了解之后发现这样的流程确实很好，又用上cookie了。

不同域下的单点登录->CAS

上面的session共享和cookie跨域问题，不过都只能限于同域下。

对内的统一登录：如果我们在一个主网站登录成功了，我们在此网站的不同功能模块中自然就处于登录状态了，比如你登录了淘宝网，那么无论你是打开某个商品详情，或是打开购物车，或者是打开自己的订单页面查看物流等信息，这时的我们都是登录状态的。使用相同父域名的服务群，可以利用cookie的特性之–允许一个子域可以设置或获取其父域的 Cookie**。Cookie中保存的数据，不论是表明了用户信息的JWT，还是SessionId，我们可以让所有服务都得到这一标志**。记得给cookie设HTTPOnly 属性来防止跨站脚本攻击。

同域下的单点登录是巧用了Cookie顶域的特性。如果是不同域呢？不同域之间Cookie是不共享的，怎么办？

什么是CAS

CAS 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（SSO的一种框架）CAS 包括两部分：CAS Server 和 CAS Client。

CAS Server：负责完成对用户的认证工作 , 需要独立部署。
CAS Client：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。

这里看懂就可以直接看最后的总结了（其余两图可以不用看）。

“重定向是服务器发起的跳转,要求客户端改用新的 URI 重新发送请求,通常会自动进行,用户是无感知的

找点中文图方便了解：

这里找了写好看点的图做笔记：分别来自话说单点登录，单点登录那些事儿（三）不同域下的单点登录，什么是单点登录（SSO）的文章截取。（此处做记录用，看完这些大抵是了解了CAS）

起初看java3y的这篇知乎文章，对于第二次访问，还有与sso建立全局会话，与系统的局部会话这些概念还是模糊（评论区下面也是没太看懂），后面找到了简书的这篇《话说单点登录》这篇文章，他对官网流程做了详细分析讲解。

sso的全局会话：写入SSO域下的Cookie。

局部会话：写入系统a或b各自域下的cookie。

上图（图一）是CAS官网上的标准流程，具体流程如下：

用户访问app系统，app系统是需要登录的，但用户现在没有登录。
跳转到CAS server，即SSO登录系统，以后图中的CAS Server我们统一叫做SSO系统。 SSO系统也没有登录，弹出用户登录页。
用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app系统，同时将ST作为参数传递给app系统。
app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。
验证通过后，app系统将登录状态写入session并设置app域下的Cookie。

至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。

用户访问app2系统，app2系统没有登录，跳转到SSO。
由于SSO已经登录(即上面写入sso域下的cookie)了，不需要重新登录认证。
SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。
app2拿到ST，后台访问SSO，验证ST是否有效。
验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。

这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。

有的同学问我，SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，觉得这个步骤有点多余。他想SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？

其实这样问题时很严重的，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的。

至此懂了用户和认证中心和多个不同域下系统认证问题。怎么tm还是用了cookie，还有这个： SSO系统登录完成后会生成一个ST（Service Ticket） 。

目前还不懂st是什么，可以理解为jwt么？（有大佬说一下么，反正就是个凭证，我觉得应该可以用jwt做凭证）

然后又继续看了看，发现有篇叫oauth2和oss的区别，我自己确实不懂，只知道三方授权登录要什么oauth2的东西，这里也简单记一下。

http认证鉴权CAS和OAuth2区别

自己对于oauth2的了解，只有在做谷粒学院用了个大概，确实是有那么个，扫码授权后返回叫code的东西回调，然后又带着code得到access_token，最后才能access_token请求得到用户信息。

二者区别主要集中在以下几个方面

目的不同

cas是用作单点登录的，oauth2是用来做授权的。

保护对象不同

cas保护的用户名密码（st可以看作用户名密码的等价物）。oauth2，保护的是code，code等价于用户名+密码+数据使用范围限制(第三方登录时，可以选择是否提供手机号，头像等信息给被授权方使用。

区别很大？并非如此

CAS和Oauth2乍一看区别很大。

OAuth2

但是如果我们将CAS的流程图拍平，也修改为OAuth2的形式进行展示。那么二者的本质就体现出来了。
如下图右侧部分

二者步骤比对图
注意：右图跳转均为重定向，所以流程不大准确。比如2，实际是返回浏览器，浏览器负责跳转（url地址会变，但信息的流动方向并没变），所以也是对的。

可见：如果忽略参与者角色命名的差异。二者流程高度相似。
oauth2流程中，从开始到获取code的步骤，和CAS高度一致。
cas登录相对oauth2，在流程上的最大区别就是，通过ST或者code去认证的时候，需不需要预先商量好的密码(appId,appSecret), _{微信登录确实需要提前申请这些}。此外还会保存CasServer下发的TGC（_{根据上一节的CAS流程中可以简单理解为与认证中心建立的全局会话cookie}）（多保存了一个信息而已，整体信息流并未变化）。
oauth2比cas覆盖更广，基本内嵌了cas步骤，不过多了一个步骤，就是通过code获取token的步骤。

笔记总结: 单点登录相关推荐

MOSS2007-学习笔记-备忘录-单点登录-（1）-我的网站'？
在上一篇文档中,描述了公司协同工作平台中遇到的问题,主要是无法和公司已有的活动目录域(active directory domain)进行用户账号的集成.到现在该软件供应商还没有给出相应的解决方案!头 ...
什么是单点登录？什么是SSO？什么是CAS？
单点登录学习笔记: 单点登录简介 SSO&CAS是什么单点登录适合什么场景单点登录的三种实现方式 CAS的几个重要知识点 CAS的实现过程
谷粒商城笔记+踩坑（17）——【认证模块】登录，用户名密码登录+微博社交登录+SpringSession+xxl-sso单点登录
导航: 谷粒商城笔记+踩坑汇总篇目录 5. 用户名密码登录 5.1[认证模块]登录业务 5.1.1 模型类,接收用户名密码 5.1.2 feign客户端新增登录功能 5.1.3 LoginContr ...
cas单点登录学习笔记 .
CAS 单点登录使用详解 ============================================================================== 开发环境 :My ...
CAS单点登录学习笔记二之部署CAS Server
CAS Server 服务器部署 [b]简介[/b] CAS Server 是一套基于 Java 实现的服务,该服务以一个 Java Web Application 单独部署在与 servlet2.3 ...
SpringCloud工作笔记072---同一浏览器上不同标签页_tab页或者同一浏览器新开一个浏览器窗口也能实现单点登录_单点登录_localStorage_sessionStorage
JAVA技术交流QQ群:170933152 注意用localStorage,存的token不会失效,可以在关闭浏览器的时候,清除或者设置一下过期时间,怎么做可以百度注意:sessionStorage ...
jasig cas java示例_单点登录cas jasig学习笔记
1 什么是单点登录单点登录(Single Sign On , 简称 SSO )是目前比较流行的服务于企业业务整合的解决方案之一, SSO 使得在多个应用系统中,用户只需要登录一次就可以访问所有相互信 ...
JSON Web Token (JWT)笔记（token实现单点登录功能）
文章目录前情提要 cookie(储存在用户本地终端上的数据) Cookie特点: session(web服务端内存) cookie和session 单点登录(只登录一次,可使用账号下全部服务)三种方 ...
基于IdentityServer4的OIDC实现单点登录(SSO)原理简析
# 写在前面 IdentityServer4的学习断断续续,兜兜转转,走了不少弯路,也花了不少时间.可能是因为没有阅读源码,也没有特别系统的学习资料,相关文章很多园子里的大佬都有涉及,有系列文章 ...

笔记总结: 单点登录