jwt 的 token 被获取怎么办

@aboat365 我发现现在凡是 token 就是 JWT……也不管合适不合适。完全就是滥用

都能被抓包了，还有什么干不了的？

都能被抓包了，还有什么干不了的？ +1
你做软件安全，总有个约束范围。 抓包侵害的是单个用户，不值得花大气力保护；
如果你涉及到资金等重要业务，可以加二次验证。 比如发送短信验证码，验证通过才能完成转账的动作。

access token 和 refresh token
access token 时间短些

也有疑问，插眼

@xuanbg 我觉得主要原因是一堆开源的快速开发平台使用了 jwt token 做无状态的身份认证，以至于带起了这股风气。而为什么这些快速开发平台选择了 jwt token,应该是前后端分离后，后端接口用 token 好调试，前端调用后端因为跨域，用 token 也方便。既然如此方便，那就这么办，至于带来的问题，如续期、token 签发时间过长导致不安全等问题，那就不考虑了，其实大部分软件也都不在乎，只要能过等保就好。至于突然 token 到期，用户强制重新登录这种体验问题，那不是问题，因为我们做的系统就几乎没人用，用也不会用很久。实在不行 token 签发时间给个几天，或者先做出来再说，后面再考虑打补丁，从无状态改成有状态，后端记录一下 token,给它续期得了。

@heyjei 随便搞个 mitmproxy 就能抓 https 了

@darknoll 普通 JWT 不需要 Refresh Token 。OAuth 才需要。注意他们的区别：

1. JWT 基本只用于对客户端的授权；特别的，经常用于浏览器并可以直接写入 Cookie 。而 OAuth 则经常用于对服务器的授权。
客户端业务逻辑除了将 JWT 发送给真正的目标之外，几乎不会将 Token 或记录到别的地方。也就是说只要本机安全（由用户自行保证）、传输层安全（ TLS ），Token 就丢不了。甚至对于浏览器来说，业务逻辑可能都看不到 JWT 的 Token 。
服务器拿到 Token 之后就不一样了，可能传输到其他服务器或存储到中间件中、可能写入日志。单一的业务逻辑很难控制。这种情况下，使用单独的、业务层不可见的 Refresh Token 就能显著提高安全性。

2. 对于客户端来说，只有用户在操作客户端时才可能发生刷新失败事件。这时候用户只要重新登录就好了；而服务器用 Token 刷新失败则可能是灾难性事件。比如当 OAuth 用于 CI 系统的拉代码逻辑，当 Token 过期且意外刷新失败时，整个 CI 都无法工作了，必须召唤管理员上线处理。这导致 OAuth 必须有一个强健的刷新逻辑。

结合业务场景设计，有的被截取也无所谓，像新闻接口基本都是 GET，展示数据的。只要保证业务安全，请求是幂等的就可以。返回的数据中有用户敏感数据就要加密

https

JWT 的能力是很有限的, 参考这个帖子里的讨论

https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens

Truly stateless JWT authentication cannot be achieved for a typical, real world web app because stateless JWT does not have a way to provide immediate and secure support for the following important use cases:
User's account is deleted/blocked/suspended.
User's password is changed.
User's roles or permissions are changed.
User is logged out by admin.
Any other application critical data in the JWT token is changed by the site admin.
You cannot wait for token expiration in these cases. The token invalidation must occur immediately. Also, you cannot trust the client not to keep and use a copy of the old token, whether with malicious intent or not.

无解 微博至今都没解决掉这个问题

@heyjei HTTPS 不是抓不到包，而是流量被加密了，如果遇到上游证书欺骗和不安全的加密方法依然可以解出来。。

建议 JWT 不要滥用，JWT 有它适合的场景的，这种需要吊销 token 的根本不适合用 JWT，一旦需要吊销，就意味着服务端需要保存相关信息，那还不如直接用 cookie+session 或者自己造轮子了

@wellsc https 是加密码的 你要解出来才有用

@glacial 所以说呢？加密了还是能抓包啊，先把证书抓下来就可以了。回帖之前你去用过我说的东西了吗

@xuanbg "换成自己的轮子吧，用服务端存 Token 的虎符模式"
能说说哪些 Token 虎符模式 的轮子比较好么?

自己造轮子的话，我的理解是: backend 的所有 services 里面得有个专门的 authentication service, 这个 auth service 通过认证 user 的主 key (e.g. password) 给用户生成 token (with expiration time). 然后, user 试图连接任何 edge services 的时候 (edge services 是我临时取的名字, 算是所有在 server mesh 边界, 链接 client users 的那些 services), edge services 都会去认证 user message 附带的 token. edge service 可以每次都去 authentication service 认证 user token, 也可以 cache user tokens 到自己 service node 上, 当然如果允许 cache user tokens 的话, auth service 撤销(revoke) user tokens 的时候, auth service 必须通知有可能 cache 过相关 user tokens 的所有 edge service nodes.

@dcoder 在我的 github 里面可以看到我自造的轮子。

我最近也正好做了一个 jwt token 签 ip 的需求，实际应用下来，略为鸡肋

机智如我，开个新主题听听大家怎么看 jwt 做会话身份认证
https://tanronggui.xyz/t/774127#reply23