session 最大的问题在于没有办法降级。
JWT 降级的手段就很多了,Redis 用来做补偿,比如生命周期的管理。踢掉用户等等...
基于 JWT 的方案对不 session 还有什么缺点呢?
1
bolide2005 2020-04-26 18:27:28 +08:00
是说每次业务鉴权都要依赖 redis 吗?在 redis 记录发出去的 jwt ?或者是在 redis 里记录作废的 jwt ?好像和 token 这个东西设计的初衷不太一致……
|
2
also24 2020-04-26 18:28:57 +08:00 via Android
|
3
also24 2020-04-26 18:35:56 +08:00 via Android
我猜测楼主的思路是:
使用 JWT 做基础的鉴权,同时使用 Redis 做补充管理(例如通过黑名单的方式提前吊销某 token ) 但这样其实抛弃了 JWT 或者说 Client side session 的不少优势: Redis 的引入导致需要依赖服务端。 服务端的引入导致需要专门处理 session 共享。 以及,如果想实现完整的生命周期管理,黑名单未必够用,可能需要引入白名单,此时这个方案实际上已经变成了 Server side session 了。 |
4
xiadada OP @also24 是变成服务端 session 了, 但是如果 Redis 挂了(只是一个服务端依赖的代表),不影响正常业务走下去, 而 Redis 挂了是小概率事件。 这套方案可以保证原来的 session 服务一定不挂。 最后一点一定不挂很吸引人啊。
|
5
also24 2020-04-26 18:46:36 +08:00 via Android
@xiadada
所谓 “一定不挂”,其实对应的是 “ session 管理未必生效” ,这是非常不严谨的。 如果你做了 session 管理功能,就不应该让它处于一种不确定是否能用的状态。 从这个角度来看,如果 Redis 挂了,那理应将整个 session 认证部分停掉,而不是 “带伤上阵” 。 |
6
xiadada OP @also24 我能 get 到你的点, 但是在业务上,我们是希望能有降级方案的。 我的管理功能只是 3 个 9,但是「校验」用户身份的功能可以做到 100%可靠。
|
7
also24 2020-04-26 18:53:07 +08:00 via Android 1
当然,并不是说完全否定这种模式,如果有这种不太严谨的业务场景,那用用倒也无妨。
本质上来说,其实就是分了两种状态。 在日常状态下,将 client side session 的 session data 作为 server side session 的 session id 使用。 在 Redis 挂掉等奇怪的状态下,退化为完全使用 client side session 机制。 |