有關於使用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