JWT+redis 能替代 session 了吗？

[xiadada]

session 最大的问题在于没有办法降级。

JWT 降级的手段就很多了，Redis 用来做补偿，比如生命周期的管理。踢掉用户等等...

基于 JWT 的方案对不 session 还有什么缺点呢？

[bolide2005]

是说每次业务鉴权都要依赖 redis 吗？在 redis 记录发出去的 jwt ？或者是在 redis 里记录作废的 jwt ？好像和 token 这个东西设计的初衷不太一致……

[also24]

https://v2ex.com/t/656457

[also24]

我猜测楼主的思路是：
使用 JWT 做基础的鉴权，同时使用 Redis 做补充管理（例如通过黑名单的方式提前吊销某 token ）

但这样其实抛弃了 JWT 或者说 Client side session 的不少优势：
Redis 的引入导致需要依赖服务端。
服务端的引入导致需要专门处理 session 共享。

以及，如果想实现完整的生命周期管理，黑名单未必够用，可能需要引入白名单，此时这个方案实际上已经变成了 Server side session 了。

[xiadada]

@also24 是变成服务端 session 了， 但是如果 Redis 挂了（只是一个服务端依赖的代表），不影响正常业务走下去， 而 Redis 挂了是小概率事件。 这套方案可以保证原来的 session 服务一定不挂。 最后一点一定不挂很吸引人啊。

[also24]

@xiadada
所谓 “一定不挂”，其实对应的是 “ session 管理未必生效” ，这是非常不严谨的。

如果你做了 session 管理功能，就不应该让它处于一种不确定是否能用的状态。

从这个角度来看，如果 Redis 挂了，那理应将整个 session 认证部分停掉，而不是 “带伤上阵” 。

[xiadada]

@also24 我能 get 到你的点， 但是在业务上，我们是希望能有降级方案的。 我的管理功能只是 3 个 9，但是「校验」用户身份的功能可以做到 100%可靠。

[also24]

当然，并不是说完全否定这种模式，如果有这种不太严谨的业务场景，那用用倒也无妨。

本质上来说，其实就是分了两种状态。
在日常状态下，将 client side session 的 session data 作为 server side session 的 session id 使用。

在 Redis 挂掉等奇怪的状态下，退化为完全使用 client side session 机制。

[also24]

@xiadada
对，这个事儿其实就是看业务场景，业务场景能接受那怎样都好说，

在日常状态下，这样其实吸取了两边的短处，性能、流量都有更多的压力。