自己学习做的笔记.没有具体代码
单点登录:多系统,单一位置登录,实现多系统同时登录的一种技术.
也就是说多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
和三方登录Oauth2是有区别的.Oauth2属于三方登录.通常是某系统,使用其他系统的用户,实现本系统登录的方式.比如京东中使用微信登录
我们可以通过Oauth2实现单点登录,但是Oauth2不是单点登录
单点登录和三方登录不是一回事,不要混肴
解决单点登录的实现方案很多,Session跨域,SpringSession共享,NginxSession共享,最主要，最常用的通过Token技术实现.相对来说用Session和JWT来实现单点登录的更多些
一、
Session
跨域
所谓
Session
跨域就是摒弃了系统（Tomcat）提供的
Session
，而使用自定义的类似
Session
的机制来保存客户端数据的一种解决方案。
如：通过设置
cookie
的
domain
来实现
cookie
的跨域传递。在
cookie
中传递一个自定义
的
session_id
。这个
session_id
是客户端的唯一标记。将这个标记作为
key
，将客户端需要保
存的数据作为
value
，在服务端进行保存（数据库保存或
NoSQL
保存）。这种机制就是
Session
的跨域解决。
绝大多数用 domain 来实现 cookie 的跨域传递实现,但是也可以用请求头信息实现.JWT技术一般用于头信息来实现跨域单点登录
-----------------------------------------------------------------------------------------------------------------------------
核心技术点:
1.HTTP,Cookie与Session
2.Cookie与Session的关系
3.Cookie,SSO令牌的载体
4.决定Cookie内容,生命周期和有效范围的7个属性
1)name和value key=value
2)expires 过期时间
3)path和domain
4)httpOnly(设置了HttpOnly的话用JS是获取不到cookie的)和secure(只在https时有效.http不可见)
5.JavaScript操作Cookie的方法 document.cookie(获取所有cookie字符串
C1=TEST1;C2=TEST2;C3=TEST3)
新增cookie document.cookie="c4=test4"
替换 document.cookie="c4=newtest4"
这里注意下,JS可以直接引入Cookie依赖操作
httpOnly不允许js操作,因此这里无法设置httpOnly,因为没任何意义
设置时间path document.cookie="c4=newtest4;expires="+[GMT时间]+";path=/xxxx;domain=www.amamaw.com;secure" secure这样写就是true
6.Java Web应用中操作Cookie的方法
7.filter.Web层拦截
大概的了解下Cookie
HttpSession session这个参数,有兴趣可以试试,有这个参数和没这个参数,对Cookie有什么影响
Cookie并没有真正的删除方式,可以设置存活时间,比如说cookie.setMaxAge(-1000),当浏览器接受到这个时候,认为该Cookie的存活时间已经过期,就不会再发送回服务端了.也可以进行Cookie覆盖,但是进行Cookie覆盖的时候必须name相同外Path,domain属性相同,不然浏览器会认为是两个不同的Cookie
注意:cookie存活时间设置为-1000 浏览器F12可能会看到还会携带过来,但是服务器接收时候是没有这个Cookie的 存活时间设置为0的话,浏览器看不到携带过来,当然服务端也不能收到这应该是浏览器的原因
关于Path和domain可以自己测试,domain就是域,在域相同的时候会携带
关于Cookie的几点
1.过多过大的Cookie浪费网络流浪
2.不同浏览器对Cookie有个数限制
3.浏览器对Cookie有大小限制
4.Cookie保存在客户端,不要在Cookie里存放敏感信息
Cookie做为SSO令牌载体,伴随着的一个问题,既然Cookie创建后,域,Path等相同会伴随着每个请求,那该在什么时间点,读取Cookie对Cookie进行权限判断？肯定不会在每个业务请求都去判断
那么就可以扯到拦截层,
Filter和Web的拦截器,监听器就不扯了吧,越扯越远写不完了
SpringBoot中实现过滤器的几种方式
这里注意下,高版本的SpringBoot很可能导致此配置无效,记得当时用的2.7.1好像,改回2.2.0以下就OK了,至于具体从哪个版本开始改动的没具体了解.
第二种直接加@Compent注解 但是这样的测试是默认所有请求都经过该过滤器,不过建议使用第三种,因不知道会不会出问题
第三种
自定义一个过滤器进行配置
同域时,Cookie传递可以设置Path为"/"
不同域是.依靠domain
spring-session
技术是
spring
提供的用于处理集群会话共享的解决方案。
spring-session
技术是将用户
session
数据保存到三方存储容器中，如：
mysql
，
redis
等。
注意:Spring-session 技术是解决同域名下的多服务器集群 session 共享问题的。不能解决跨域
session 共享问题。注意不能解决跨域共享！！！注意不能解决跨域共享！！！注意不能解决跨域共享！！！
三、
Nginx Session
共享
nginx
中的
ip_hash
技术能够将某个
ip
的请求定向到同一台后端，这样一来这个
ip
下的
某个客户端和某个后端就能建立起稳固的
session
ip_hash
是容易理解的，但是因为仅仅能用
ip
这个因子来分配后端，
因此 ip_hash 是有
缺陷的，不能在一些情况下使用：
nginx
不是最前端的服务器。
ip_hash
要求
nginx
一定是最前端的服务器，否则
nginx
得不到正确
ip
，就不能根据
ip
作
hash
。譬如使用的是
squid
为最前端，那么
nginx
取
ip
时只能得到
squid
的服务器
ip
地址，
用这个地址来作分流是肯定错乱的。
nginx
的后端还有其它方式的负载均衡。
假如
nginx
后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端
的请求肯定不能定位到同一台
session
应用服务器上。
nginx演示配置 通过开启ip_hash来实现Session对应服务器,但是不推荐使用
四、
Token
机制(SSO单点登录主流实现方案)
JSON Web Token JWT 可以当成实现Token的有效方案
JWT是一种紧凑(数据量小)且自包含(使用JWT的payload记录用户必要且不隐私的数据,这样减少数据库访问),用于多方传递JSON对象的技术.
JWT一般用于处理用户身份验证或数据信息交换.
JWT
数据结构
JWT
的数据结构是 ：
A.B.C
。 由字符点‘.’来分隔三部分数据。
A - header 头信息:{“alg”: “
加密算法名称
”, “typ” : “JWT”}
B - payload
（有效荷载）:三部分唯一可以不传的,但是不传不代表没有
payload中常用信息有已注册信息(registered claims),公开数据(public claims),私有数据(private claims),公开数据和私有数据可以自定义,但是不要和已注册信息Key重名,可以配置
C - Signature 签名:
用
header
中定义的加密算法，将
header
和
payload
进行加密，并使用点进行连接。如：加密后的
head.
加密后的
payload
。再使用相同的加密算
法，对加密后的数据和签名信息进行加密。得到最终结果。
大致执行流程:
