前端和後端分離架構的現狀:
在這種情況下，後端api是暴露在外網的，因為常規web項目的前端無論如何都會通過公網訪問後端api，這也帶來了很多隱患。
1.界面是開放的，任何人都可以訪問。
2.數據請求的參數在傳輸過程中被篡改。
3.接口被重復調用。
...
會話和cookie是客戶端和服務器之間通信所需的身份驗證。當客戶端的值與服務器的值壹致時，允許請求api，解決了1問題。但是，當攻擊者在傳輸過程中獲得會話或cookie值時，就可以進行第二次和第三次攻擊。
JWT標準令牌包含三個部分:
報頭用於描述JWT的最基本信息，例如其類型和用於簽名的算法。
下面的字符串可以通過[base64編碼]上面的JSON對象獲得。這個字符串被稱為JWT的標題。
Payload也是壹個JSON對象。包含壹些其他信息。
前五個字段由JWT標準定義。
下面的字符串可以通過[base64編碼]上面的JSON對象獲得。這根繩子被稱為JWT的有效載荷。
將上面兩個編碼後的字符串用句點(頭在前面)連接起來，形成。
最後，我們用HS256算法對拼接後的字符串進行加密。加密時，我們還需要提供壹個秘密。如果我們用mystar作為密鑰，就可以得到我們的加密內容。
這部分叫做簽名。
最後，簽名的這壹部分也被拼接在已簽名的字符串之後，我們得到了完整的JWT。
簽名解決了數據傳輸過程中參數篡改的風險。
壹般來說，加密算法總是對不同的輸入產生不同的輸出。如果有人對報頭和有效載荷的內容進行解碼、修改和編碼，那麽新的報頭和有效載荷的簽名將與以前的不同。而且，如果不知道服務器加密時使用的密鑰，簽名肯定不壹樣。
篡改數據的問題解決了，還有第三個問題，就是攻擊者不修改數據，只是重復攻擊。
例如，瀏覽器端用戶名/密碼驗證簽名的令牌被特洛伊木馬竊取。即使用戶註銷了系統，黑客仍然可以使用竊取的令牌來模擬正常的請求，但是服務器對此壹無所知，因為JWT機制是無狀態的。
您可以在有效負載中添加時間戳，前端和後端都參與解決這個問題: