请教大家一个关于 RESTFul 认证的问题：如何保证一个用户只能有一个 JWT（ Json Web Token）

[mynameisny]

本人菜鸟，目前在开发几个 RESTFul API 。现在遇见一个头疼的问题，希望大家不吝指教：

如何能保证一个用户在一段时间内只能有一个 Token 是可用的？

---- 用户在某一个时刻只能有一个有效 Token ，即，用户已有一个有效 Token 时，再次请求 Token 时要作废之前生成的那个 Token 。

---

实际的业务流程是：

• 需要调用者先使用用户名和密码去签定身份
• 鉴定成功，服务器返回一个 Token
• 调用者之后再调用其他 API 时就在 HTTP Authorization Header 中带着这个 Token

目前采用的方案是：

• 使用 jjwt 生成 Token ，保存在 Redis 中，以用户名作为 Key
• 通过设置 Redis 键的 TTL 来实现 Token 自动过期
• 通过在 Servlet Filter 中拦截请求判断 Token 是否有效
• 由于 Redis 是基于 Key-Value 进行存储，因此可以实现新的 Token 将覆盖旧的 Token ，保证一个用户在一个时间段只有一个可用 Token

问题和纠结是：

• 查阅了好多资料都提到 RESTFul API 通常被设计成无状态的，采用 JWT （ Json Web Token ）进行认证是不需要将生成的 Token 保存在 Session 中的，那现在我的方案明显就是相悖的。
• 在我现在的方案中，如果用户担心旧的 Token 已经被泄漏，可以重新生成一个 Token ，那么旧的 Token 就会过期，这是很好的结果。但是如果用户写好的某个调用程序正在执行，不小心又重新生成了一个 Token ，那么调用就会停止。如何避免这种情况？

[mynameisny]

@Koyoter 可能是误解了，并不是讨论 Token 绑定用户的问题，同一用户同一 IP 同一 MAC ，在同一时刻生成了多个有效 Token 。

[future0906]

@mynameisny

我没有用过 JWT ，但是我猜应该是类似于 signed-json 的东西，这个和 token 本质上是有区别的，用来做简单的鉴权可以，真正做 API 的话必须保存一个 token=>auth_state_dict 的一个关系。这个好处是服务端可以控制这个鉴权的信息（权限变更之类的）

你关键的问题在于对 RESTFul 对 stateless 的误解，所谓的 stateless 是对 HTTP 层来说的，对于 HTTP 后面的资源根本没有办法做到 stateless （不然怎么保存用户数据？）。

所以传统意义的 session （ http 层）肯定不能用，只能是存在数据库中，以保证服务可以 fail-over 。

[mynameisny]

@future0906 您提到的“ stateless 是对 HTTP 层来说的”这点理解了，但是不能将这个 Token 放在 session 中实现 fail-over 这块还是不怎么明白，烦请再帮忙讲一下。

可不可以只在用户的 SESSION 作用域中保存一份唯一的 Token ，再次请求 Token 的时候就生成并覆盖 SESSION 中这个 Token 。同时保证每次拦截认证都是从 SESSION 获取这个唯一 Token ？