v2ex上的讨论说得比较明白：[前后端分离， JWT 还是 Oauth2?](https://www.v2ex.com/amp/t/439613/2)
个人总结：
1. jwt 用于频繁且不敏感的操作
很大程度上 token 的作用就是为了在请求量比较大且多终端复用的情况下，减少登录和用户数据查询操作产生的数据库压力，如果每次还需要检查 token 版本，不如直接用最基本的 session 来实现；修改密码需要多终端下线的操作，可以通过向终端发送重新登录的通知来实现，如果担心之前的 token 没作废产生的安全风险，应该把在敏感场景中排除 token 的效力。比如，正常的查询操作都可以使用 token，是不会触发重新登录的操作的，但如果涉及到财产、敏感信息的查询和操作，都应该进行重新登录并用 session 维护登录信息。token 永远不是安全性高的解决方案。token 也不是为了这种场景存在的。
2. JWT的设计中包含了 expire time，方案是放在 jwt 的 payload 中； token 刷新预留一个 path 就 ok 了，访问这个 path，提取并验证用户信息后发一个新的 token 返回给客户端；后端禁用在 jwt 的设计中是不能实现的，当然你可以在数据库里保存 token 并标记，但这违反了 jwt 的设计原则，要真是有这样的需求，说明你的使用场景不适合 jwt
3. 如果你需要以下功能，JWT不适用
第一：对 token 刷新使用期限
第二：支持 token 失效
4. JWT 的过期和刷新，未看
参考业界主流做法，AWS、Azure 和 Auth0 都是用 JWT 为载体，ID Token + Access Token + Refresh Token 的模式：
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-token-and-claims
https://auth0.com/docs/tokens
可能参考的文章：
1. https://www.cnblogs.com/EasonJim/p/7824293.html