极客时间-如何降低用户鉴权的流量压力

背景

内容是极客时间-徐长龙老师的高并发系统实战课的个人学习笔记,欢迎大家学习!https://time.geekbang.org/column/article/596644

使用Session方式实现用户的用户鉴权

优点

信息都在服务端储存,对客户端不暴露任何用户敏感的数据信息

缺点

  1. Session Cache空间会变得很大
  2. Session Cache和各个子系统的耦合度极高,全站的请求都会对这个缓存至少访问一次

使用jwt登陆和token校验

用户登陆之后会将用户信息放到一个加密签名的token中,每次请求都把这个串放到header或者cookie内带到服务端。服务端解开这个token即可获取用户的信息

token=header+payload+signature

header: 保存加密算法类型

payload: 自定义的内容(用户昵称,uid,过期时间等等)

signature: 防篡改签名

解密

token,第一段和第二段通过base64编码

验证是否过期,其中的过期时间和本地时间对比一下即可

流程图

缺点

如果用户被拉黑了,客户端最快也要在token过期之后才能推出登陆,时效性较低

token的更换和离线

一般使用两种token=refresh_token+access_token

refresh_token用于更换access_token,有效期是30天;

access_token用于保存当前用户信息和权限信息,每隔15分钟更换一次

如果用户中心请求失败,APP处于离线状态,只要检测到本地的refresh_token没有过期,系统仍可以继续工作,直到refresh_token过期为止。

流程图

总结

个人理解:

其实Session和token的方式完全可以结合起来用

  1. Session 耦合性高,实时性高
  2. Token 耦合性不高,实时性低

问题

使用base64加密是不是不太安全?这样不是很容易知道你用什么加密算法了

这个算法重点并不是这个payload区,payload这里只是附带的数据,只是为了方便业务使用,事实上这个核心在于签名和过期时间,由于密钥是只有服务端有,所以签名是不能伪造的,如果到子业务这里验证签名是正确的密钥加密的,那么代表token的payload的内容肯定是服务器发放的,传输的用户无法更改,如果更改了就会和签名核对不上,通过这个方式就已经能够保证数据的安全了。至于base64内放的数据普遍是可以公开的信息,如果有不能公开的信息可以再做一层加密后再放入payload

用户如果更换了昵称,如何快速更换 token 中保存的用户昵称呢?

  1. 客户端可以缓存修改后的昵称,直到更换了access token再清除缓存,类似弹幕本地先发送让用户自己认为发送成功
  2. 有些为了业务方便,token可以有额外的信息放在结尾,如果这个信息用户常修改则不应该放在token里面,单独弄个接口不是直接解决问题。
相关推荐
极光雨雨几秒前
Spring Bean 控制销毁顺序的方法总结
java·spring
念九_ysl19 分钟前
Java 使用 OpenHTMLToPDF + Batik 将含 SVG 遮罩的 HTML 转为 PDF 的完整实践
java·开发语言·pdf
yaoxin52112328 分钟前
124. Java 泛型 - 有界类型参数
java·开发语言
Spirit_NKlaus31 分钟前
解决HttpServletRequest无法获取@RequestBody修饰的参数
java·spring boot·spring
不死的精灵37 分钟前
【Java21】在spring boot中使用ScopedValue
java·spring boot·后端
勤奋的知更鸟1 小时前
Java 编程之模板方法模式
java·开发语言·模板方法模式
M1A11 小时前
TCP/IP协议精解:IP协议——互联网世界的邮政编码系统
后端·网络协议·tcp/ip
逸风尊者1 小时前
开发易掌握的知识:GeoHash查找附近空闲车辆
java·后端
碎叶城李白2 小时前
若依学习笔记1-validated
java·笔记·学习·validated
都叫我大帅哥2 小时前
🌊 Redis Stream深度探险:从秒杀系统到面试通关
java·redis