有关于使用JWT实现先后端分离的疑惑

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