服务端生成 Token 后为什么要存储？

从JWT官方文档中我们了解到，JSON WEB TOKEN 由三部分组成：

Header

Payload

Signature

这里我们只说Payload 中的保存内容，引自JWT官方：

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata. There are three types of claims: registered, public, and private claims.

从这里我们可以看出，token 的 Payload 部分是具备存储用户ID，角色的能力的。也就是充分体现了 TOKEN 自解释的特点。

既然这样，我们为什么要在类似 Redis 这种缓存数据库中对 Token 进行持久化呢？完全可以由客户端对 Token 持久化呀？

咨询过朋友，大多数给我的回答是，访问速度快，方便过期。

那么我们假设如果不在后端存储 Token，Payload 中的信息为：

{

"id": "1234567890",

"name": "John Doe",

"admin": true

"expire": 1527833009000

}

那么当客户端携带这个 token 访问服务端的时候，服务端进行两步处理：

对 Signature 部分进行解密验证，保证 token 没有被篡改过。

解析 Payload 数据，根据属性 expire 来判断是否过期

那么我们是否可以避免每次客户端访问的时候去 redis 中检索 token 了呢？

现在大家在客户端携带 token 访问服务端的时候，是否每次都需要去 redis 中进行验证呢？

同样在微服务的架构设计中，对外提供服务的可能是一个API网关，或者多个API网关，那么我们的 Redis 必然安装在一个独立的物理机或者VM上，那么我们每次对token 进行有效性检查时，是否都是要连接远程的 Redis 服务器检索数据，然后验证呢？

感谢大家！

回答

JWT 是不需要存服务端的，我也很奇怪为什么有人会把token存服务端。而且即使存服务端，也应该当成密码一样加密存储。不然数据库被 hack 里，token 就都拿到了，不用密码就可以冒充用户发请求了。

JWT的一大优点就是不需要服务器端存储，token是直接存储在客户端的，每次请求都带上token，三段中的最后一段用于校验token是否有变动，以防止客户端恶意篡改。

当然，最大的缺点来自于其优点，token大小与携带数据成正比，所以推荐只在其中保存用户唯一标示，其余现查。

还有，楼上说的安全问题，中间人攻击或者客户端遭到攻击，无论哪种认证方式都无软用。