单点登录相关

实现单点登录的两种方式

• 有状态的单点登录

登录功能的发展

1. 单一服务器模式
   最开始使用session.setAttribute()和session.getAttributed,这是以前的单一架构,session全部放在一个服务器上

一般流程如下:

• 用户向服务器发送用户名和密码。
• 验证服务器后，相关数据（如用户名，用户角色等）将保存在当前会话（session）中。
• 服务器向用户返回session_id，session信息都会写入到用户的Cookie。
• 用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。
• 服务器收到session_id并对比之前保存的数据，确认用户的身份。
  

2. session共享模式
   后面出现分布式系统,分布式系统一定会设置到数据共享问题,但session只作用于当前服务器,每个服务器上都需要session校验,所以就出现了session共享,所有的session专门放在一个地方,一般使用redis缓存
   

3.SSO
分布式，SSO(single sign on)模式：单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

大型的企业,会直接把session共享直接去掉了,弃用session,直接使用redis数据库,把user数据直接存放在redis.并且这些用户校验授权服务可以专门用一个微服务来管理(cas注册中心),又这个微服务去redis中校验token,其他微服务都是靠这个专门管用户登录状态的微服务管理.

在弃用session后,它的jsessionid和相关方法也无法使用了,因为jsessionid起到的作用是令牌的作用,所以使用token令牌机制直接替代了jessionid. token在客户端放在cookie中,在服务器放在redis中 , 简而言之,以前的session机制=现在的token+redis机制,

一般过程如下：

• 当业务A、业务B需要登录时，将跳到SSO系统。

• SSO从用户信息数据库中获取用户信息并校验用户信息，SSO系统完成登录。
  然后将用户信息存入缓存（例如redis）。

• 当用户访问业务A或业务B，需要判断用户是否登录时，将跳转到SSO系统中进行用户身份验证，SSO判断缓存中是否存在用户身份信息。

• 这样，只要其中一个系统完成登录，其他的应用系统也就随之登录了。这就是单点登录（SSO）的定义。
  
  

• 无状态的单点登录(token模式)

无状态的单点登录的设计模式，那么如何在服务器不保存用户的登录状态和登录信息的情况下实现单点登陆呢？

服务器直接不保存用户的登录状态和信息,登陆成功后会给客户端颁发一个令牌,靠token+算法解决验证问题,这个token也叫做自包含token(包含了用户的信息),比如身份证就是典型的自包含token,由于里面包含了个人信息,所以就需要算法加密

有状态和无状态对比(性能上,安全性,复杂性)

• 性能上:一个放在缓存中,费内存,一个使用了算法,费cpu,如果内存够大能够抗住高并发,如果cpu性能不够优秀,扛不住高并发

• 安全性:cas的安全性更好,无状态的token有包含用户信息,不安全

• 复杂性:cas会更复杂些,无状态会更简单搭建

使用Jwt : Jwt 全称json web token 是一个用来生成网络自包含令牌的小工具

加密由三部分组成：

jwt头部，token类型和加密或者签名算法等信息

B载荷，自包含信息本身,可以包括用户信息,不要放入用户密码,必须添加

C签名，用来防伪的网络签名.可以不添加但是不添加就不能防伪,但是密钥在有细微差别的情况下也会被破解,所以具有很大安全隐患,例如ip地址的数字有差别但是不大的情况(127.0.0.1He127.0.0.2)所以签名的密钥需要通过MD5或其他加密方式进行再次加密作为密钥