单点登录
1.单点登录
单点登录(Single Sign On),简称为SSO。简单来说,指在同一帐号平台下的多个应用系统中,用户只需登录一次,即可访问所有相互信任的系统。简而言之,多个系统,统一登陆。
实现单点登录(SSO)有几种常见的方式,其中一些主要方法包括:
- 基于cookie + redis实现
1.1 基于cookie + redis + 网关实现
SpringBoot集成redis+cookie实现分布式单点登录
很早之前, 我们尝试过实现单系统(垂直架构单实例)中实现单点登录, 当时采用的方案是cookie + session。
使用session实现单点登录, 它不适用于服务拆分、多实例的场景. 使用Redis替代基于服务器端Session存储的方式, 可以解决多实例和服务拆分的问题, 并且能够提供更高的性能和可扩展性. Redis作为一种高性能的分布式内存数据库,有以下优势:
- 高性能: Redis是一种基于内存的数据库,读写性能非常高。与传统的基于磁盘的Session存储相比,基于Redis的存储能够提供更低的延迟和更高的吞吐量。
- 分布式支持: Redis支持分布式部署和数据复制,能够实现数据的高可用性和容错性。这意味着即使一个Redis节点失效,系统仍然可以继续运行。
- 持久化: Redis支持分布式部署和数据复制,能够实现数据的高可用性和容错性。这意味着即使一个Redis节点失效,系统仍然可以继续运行。
Redis非常适合用于存储会话信息和实现单点登录功能。通过使用Redis,你可以将用户的认证状态存储在分布式的内存数据库中,从而实现跨多个服务实例的会话共享和管理,提高系统的性能、可靠性和可扩展性。
1.1.1 实现原理
使用cookie + redis可以实现sso, 但在服务拆分的情况下, 需要在每个服务中都设置请求拦截器来判断请求携带的Token是否有效, 这样造成了代码的重复, 所以可以考虑引入一个专门的服务去处理身份认证, 所有的客户端请求都首先发送到身份认证服务。身份认证服务负责验证用户的身份,并根据需要转发请求到后端的服务。我们可以使用网关来实现此功能
- 登录成功后生成Token: 网关放行登录请求, 用户登录成功后, 后端生成一个唯一访问令牌(例如UUID), 即Token
- 将Token响应给浏览器: 将Token存在cookie中, 并cookie设置有效时间30分钟(模拟30分钟会话)
- Token存储在redis中: 将令牌和用户信息以key-value的形式存储在redis中, Token作为key, 用户信息为value, 并设置有效时间30分钟. 这样, 不同服务实例都可以通过Token来识别用户的身份。
- 网关统一认证: 所有服务的访问请求都经过网关, 在网关中设置拦截器进行统一认证和授权. 当用户发送请求到网关时, 网关会检查请求中携带的Cookie中是否包含认证令牌.
- 身份认证: 网关从cookie中提取认证令牌,然后在redis中验证令牌的有效性。如果令牌有效,则用户已经登录;否则,用户需要重新登录或者跳转到认证页面。
- 转发请求: 如果用户已经登录,网关会将请求转发到相应的服务,并将认证令牌一并传递给服务。服务可以通过令牌来获取用户的身份信息,以及进行其他权限验证等操作。
- 单点注销: 当用户注销登录时,网关需要通知所有服务将用户的认证令牌从Redis中删除,确保用户在所有服务中都需要重新登录。
1.3 Token机制
1.3.1 传统身份认证
HTTP是一种没有状态的协议,也就是它并不知道是谁在访问应用,这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求时,还得再校验一次。这明显是不合适的,如果客户每次访问应用都需要登录验证、登录验证…客户体验会非常差
解决方式:当客户请求登录的时候,如果没有问题,我们在服务端生成一条记录,这个记录里可以说明一下登录的用户是谁,然后把这条记录的ID编号发给客户端,客户端收到以后将ID编号存储在Cookie中,下次这个用户再向服务端发送请求的时候,可以携带这个Cookie,这样服务端就会验证这个Cookie里的信息,看看能不能在服务端这里找到对应的记录,如果可以,说明用户已经通过了身份验证,就把用户请求的数据返回给客户端。
上面说的就是HTTP Session,我们需要在服务端存储为登录的用户生成的Session,这些Session可能会存储在内存、磁盘、或者数据库里。我们可能需要在服务端定期的去清理过期的Session
这种认证出现的问题是:
- 内存开销问题:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时,内存的开销也会不断增加。
- 可扩展性:在服务器的内存中使用Session存储用户信息,伴随而来的是可扩展性问题。
1.3.2 基于Token的身份认证
使用基于Token的身份认证方式, 在服务端不需要存储用户的登录记录, 大概的流程是这样的:
- 客户端使用用户名、密码请求登录
- 服务端收到请求, 验证用户名、密码
- 验证成功后, 服务端会签发一个Token, 再把这个Token发送给客户端
- 客户端收到Token以后可以把它存储起来, 比如放在Cookie里或者Local Storage里
- 客户端每次向服务端请求资源时携带服务端签发的Token
- 服务器收到请求, 然后去验证客户端请求里面带着的Token, 如果验证成功, 就向客户端返回请求的数据
使用Token的优势:
- 无状态、可扩展
在客户端存储的Tokens是无状态的, 并且能够被扩展. 基于这种无状态和不存储Session信息, 负载均衡器能够将用户信息从一个服务器传到其他服务器上 - 安全性
请求中发送Token而不再是发送Cookie能够防止CSRF(跨站请求伪造). 即使在客户端使用Cokkie存储Token, Cookie也仅仅是一个存储机制而不是用于认证, 不将信息存储在Session中, 让我们少了对Session的操作
1.4 JWT机制
JWT(JSON Web Token)
JWT是一种紧凑
、自包含
的, 用于在多方传递JSON对象的技术. 传递的数据可以使用数字签名增加其安全性. 可以使用HMAC加密算法或RSA公钥/私钥加密方式
- 紧凑:数据小, 可以通过URL, POST参数, 请求头发送. 且数据小代表传输速度快
- 自包含:使用payload数据块记录用户必要且不隐私的数据, 可以有效的减少数据库访问次数, 提高代码能力
JWT是一般用于处理用户身份验证
、数据信息交换
- 用户身份验证:一旦用户登录, 每个后续请求都将包含JWT, 允许用户访问该令牌允许的路由、服务和资源. 单点登录是当今广泛使用JWT的一项功能, 因为它的开销很小, 能够轻松的跨域使用
- 数据信息交换:JWT是一种非常方便的多方传递数据的载体, 因为其可以使用数据签名来保证数据的有效性和安全性
1.4.1 JWT数据结构
JWT的数据结构是:A.B.C
由字符点"."来分隔三部分数据
- A:header 头信息
- B:payload 有效荷载
- C:Signature 签名
1.4.1.1 header
数据结构:
{"alg":"加密算法名称", "typ": "JWT"}
- alg是加密算法定义内容, 例如HMAC、SHA256、RSA
- typ是token类型, 这里固定为JWT
1.4.1.2 payload
在payload数据块中一般用于记录实体(通常为用户信息)或其他数据的, 主要分为三个部分. 分别是
- 已注册信息(registered claims).
- 公开数据(public claims)
- 私有数据(private claims)
已注册信息(最重要的数据), 包括: iss(发行者), exp(到期时间), sub(主题), aud(受众)等…
公开数据部分一般都会在JWT注册表中增加定义, 避免和已注册信息冲突
公开数据和私有数据可以由程序员任意定义
1.4.1.3 signature
签名信息, 这是一个由开发者提供的信息, 是服务器验证的传递的数据是否有效安全的标准, 在生成JWT最终数据之前, 先使用header中定义的加密算法, 将header和payload进行加密, 并使用点进行连接, 如:加密后的head.加密后的payload, 再使用相同的加密算法, 对加密后的数据和签名信息进行加密, 得到最终结果
1.4.2 JWT执行流程
1.客户端(browser)发起post请求, 请求的路径为/users/login,需要提供用户名和密码
2.服务端(server)对用户名和密码校验, 校验通过后, 会生成一个JWT的加密字符串(secret), 这个字符串就是token
3.把JWT返回给客户端浏览器(browser), 浏览器将JWT存储起来
4.后期, 客户端(browser)再发起请求, 需要在请求头里加上JWT(建议是将JWT放header中)
5.服务端(server)校验JWT, 判断是否登录