SSO笔记

自己学习做的笔记.没有具体代码

单点登录:多系统,单一位置登录,实现多系统同时登录的一种技术.

也就是说多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

和三方登录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-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。再使用相同的加密算

法，对加密后的数据和签名信息进行加密。得到最终结果。

大致执行流程: