JWT 可以实现 stateless authentication，但是 refresh token 不是无状态的，那 JWT 的意义是什么？

[JasonLaw]

相关资料：

• security - JWT refresh token flow - Stack Overflow中的一个回答
• Stateless authentication with JWT: refresh token is not stateless - Information Security Stack Exchange

我的疑问：

如果使用 JWT 实现 stateless authentication 的话，那么肯定会使用到 refresh token，也就是会存储 refresh token 和 user 的对应关系。那么为什么还要使用 JWT 呢？为什么不直接使用opaque token呢？

额外阅读：

Authentication as a Microservice - YouTube

[LeeReamond]

@freakxx 像我上面说的，httponly 的东西，其实不太清楚怎么才能泄露，如果不会泄露的话，更改密码后旧 cookie 感觉不禁用也无所谓。

同一时间只能单平台登录这个倒是确实有问题，这个场景也许天生 jwt

[LeeReamond]

@LeeReamond 也许天生不适合 jwt

[KuroNekoFan]

感觉 jwt 的价值在于提供了一种机制验证两端的敏感信息是可信任的吧

[IvanLi127]

@uptonking #19 省空间，集群或者多服务下不用想着怎么共享数据。

[johnsona]

面试用的，你懂什么，不说一句 jwt 都不好意思见人

[Kaciras]

连设备一起泄露不就行了。

用户手机被盗，登陆过保存了 JWT，重置密码后让原先登录失效，这 JWT 就做不了。

[iConnect]

@LeeReamond 用户账号重要的话，必须实时踢下线，否则账号被盗、意外泄露密码这些情况，就只能干瞪眼了。

[dorothyREN]

用数据库存储的一会密码做 jwt 的 key，这样修改过密码以后 token 就自然失效了

[Smash]

@Kaciras #26 可以做到的，把原先的 JWT 加入到黑名单即可。

[Kaciras]

@Smash 黑名单总得保存到哪里，这就不是 stateless 的了

[VHacker1989]

都回答到点子上，jwt 里面有个 expire 字段，是根据这个来判断是否过期的

[lyqqqq]

一些项目一开始用 jwt，也只判断过期时间。架不住后面提了新需求需要踢下线，干不过产品。不想重新改认证。只能做个黑名单。

[leeg810312]

jwt 有很多特性，也许最开始是包含无状态的设计意图，但在我看来这不是它最有用的特性，无状态不符合安全需求完全可以忽略这个特性。

我觉得 jwt 最有价值的特性：可以跨多个域名验证，Web 服务器能以任意网络拓扑结构横向扩展而不影响校验，客户端可以多种方式保存（浏览器 cookie 、HTML 存储对象、APP 用户数据文件等）或发送（ URL 参数、form 表单等）。你当然可以自搞一套来满足这些需求，但 jwt 这样非常细节具体的一个标准很容易进行行业标准化实现，所以网上各种开发平台不同公司和开发者实现的 jwt 类库和产品都是相容的，可以开箱即用，节省大量开发成本。

[sampeng]

jwt 和 refres token 是两回事…用 jwt 可以不用 refresh token 啊。用 refresh token 也可以不用 jwt…

[nvkou]

其实可以参考 sso 接入的做法。
jwt 只是替代了密码来验证身份而已。使用 refresh token 只是协调最新身份信息，达到类似 session 的效果。而对于服务端来说业务可以不理会 jwt，自己管理 session （仅验证身份）。那么在需要强制下线的场景下服务端可以先使自身管理的 session 失效，再通过业务向自营 sso 后台管理用户（全局下线或者锁定账户）。
普通场景下服务端可以根据业务设置合理的 session 时间，自营 sso 则授权较长的时间。在用户眼里就是请求的时候有可能会有一瞬间的重定向到 sso 获取当前服务端的 session，此场景也适用于横向扩展。

我们是用的 keycloak 作为 sso 服务，同时也是其他 sso 的 broker 。 保证自己有绝对控制权和权限分配。另外其实 SAML 协议的功能更完善些

[nvkou]

我之前也想过这个问题。jwt 的有效性靠数字签名保障而已，无篡改是 ok 的，但信息的时效性却很难保证，毕竟钥匙已经发出去了。虽然用户信息是集中在 sso 服务器，改密码等操作自然可以 void 掉当前所有的授权。但也有可能服务端会有需求终止授权或权限变更。那么一个隐秘的 service account 用于从服务端操作 sso 服务器就很有必要了。 如果完全信任社会化登录（ qq，微信，微博，google，apple ）就无法满足要求。既然用户的关键数据需要自行管理（权限，黑名单等）。到不如自己也做个 sso 中转一下，反正也是 K-V 而已

[codehz]

@qwerthhusn #6
（黑名单比白名单好的一点是：你可以中央服务器分发黑名单的布隆过滤器参数，这种过滤刚好适合于黑名单，因为不可能漏，只能将有效的错误检测为无效的，此时才需要发请求确认，可以大大降低查询的机会，而 push 模式也使得每个服务器需要保持的状态很少，更便于同步。。。（当然，可能会出现延迟，但是你可以让登记黑名单的步骤等待同步完成后才返回，就可以避免状态不一致）

[falcon05]

用上 refresh token 就变成 statefull 的了，跟传统的 session 相差不大，我看了它的实现，是在服务端使用表保存不同 app 的 token，方便直接销毁 token，这样可以做到有些场景，比如用户设备丢失，手动移除该设备的登录状态

[LeeReamond]

@codehz 非常合理，感觉也许是这个问题的最终解答了

[micean]

jwt 的主要场景是 api 授权