单点登录（SSO）

SSO：Single Sign On，即：单点登录

单点登录表现为：在集群或分布式系统中，客户端在其中的某1个服务器登录，后续的请求被分配到其它服务器处理时，其它服务器也能识别用户的身份。

单点登录的实现方案有：

• 共享Session

  • 把所有客户端的Session数据存储到专门的服务器上，其它任何服务器需要识别客户端身份时，都从这个专门的服务器上去查找、读取Session数据

  • 缺点：Session的有效期不宜过长

  • 优点：编码简单，读取Session数据基本上没有额外牺牲性能

• Token

  • 当某客户端登录成功，服务器端将响应Token到客户端，在后续的访问中，客户端自行携带Token数据来访问任何服务器，且任何服务器都具备解析此Token的功能，即可识别客户端的身份

  • JWT（JSON Web Token）也是Token的一种

  • 缺点：编写代码略难，需要频繁解析JWT，需要牺牲一部分性能来进行解析

  • 优点：可以长时间有效

 

普通单体项目登录的问题

微服务架构下,要解决单点登录实现会话保持的问题

首先我们分析一下普通登录和微服务登录的区别

先是单体项目登录之后的操作流程

主要依靠服务器的session保存用户信息

客户端发请求时,将sessionid同时发往服务器,根据sessionid就能确认用户身份

分布式或微服务项目中,服务器不再只有一个

那么就会出现下面的问题

上面的图片,表示我们在微服务系统中登录时遇到的问题

我们在用户模块中登录,只是将用户信息保存在用户模块的session中

而这个session不会和其他模块共享

所以在我们访问购物车模块或其他模块时,通过sessionid并不能获得在用户模块中登录成功的信息

这样就丢失的用户信息,不能完成业务,会话保持就失败了

市面上现在大多使用JWT来实现微服务架构下的会话保持

也就是在一个服务器上登录成功后,微服务的其他模块也能识别用户的登录信息

这个技术就是单点登录

单点登录解决方案

Session共享

Session共享是能够实现单点登录效果的

这种方式的核心思想是将用户的登录信息共享给其他模块

适用于小型的,用户量不大的微服务项目

将登录成功的用户信息共享给Redis

其他模块根据sessionId获得Redis中保存的用户信息即可

• 这样做最大的缺点就是内存严重冗余,不适合大量用户的微服务项目

JWT单点登录

Json Web Token(令牌)

这种登录方式,最大的优点就是不占用内存

 

生成的JWT由客户端自己保存,不占用服务器内存

在需要表明自己用户身份\信息时,将JWT信息保存到请求头中发送请求即可

Jwt登录流程图