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

发布时间:2024年01月12日

背景

内容是极客时间-徐长龙老师的高并发系统实战课的个人学习笔记,欢迎大家学习!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里面,单独弄个接口不是直接解决问题。
文章来源:https://blog.csdn.net/qq_41124175/article/details/135541598
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。