前後端分離架構帶來的好處壹搜壹大堆，我們來看壹下分離後後端接口的安全問題。
前後端分離架構現狀：
這樣的情況後端api是暴露在外網中，因為常規的web項目無論如何前端都是要通過公網訪問到後臺api的，帶來的隱患也有很多。
1.接口公開，誰都可以訪問
2.數據請求的參數在傳輸過程被篡改
3.接口被重復調用
...
session和cookie都是客戶端與服務端通訊需要提供的認證，當客戶端的值和服務器的值吻合時，才允許請求api，解決了第1個問題，但是當攻擊者獲取到了傳輸過程中的session或者cookie值後，就可以進行第2、3種攻擊了
JWT標準的token包含三部分：
頭部用於描述關於該JWT的最基本的信息，例如其類型以及簽名所用的算法等
將上面的JSON對象進行 [base64編碼] 可以得到下面的字符串。這個字符串我們將它稱作JWT的Header
Payload也是壹個JSON對象。包含了壹些其他的信息
這裏面的前五個字段都是由JWT的標準所定義的。
將上面的JSON對象進行 [base64編碼] 可以得到下面的字符串。這個字符串我們將它稱作JWT的Payload
將上面的兩個編碼後的字符串都用句號 . 連接在壹起（頭部在前），就形成了
最後，我們將上面拼接完的字符串用 HS256算法 進行加密。在加密的時候，我們還需要提供壹個 密鑰（secret） 。如果我們用 mystar 作為密鑰的話，那麽就可以得到我們加密後的內容
這壹部分叫做 簽名
最後將這壹部分簽名也拼接在被簽名的字符串後面，我們就得到了完整的JWT
簽名解決了數據傳輸過程中參數被篡改的風險
壹般而言，加密算法對於不同的輸入產生的輸出總是不壹樣的，如果有人 對Header以及Payload的內容解碼之後進行修改，再進行編碼的話，那麽新的頭部和載荷的簽名和之前的簽名就將是不壹樣的。 而且，如果不知道服務器加密的時候用的密鑰的話，得出來的簽名也壹定會是不壹樣的。
解決了篡改數據的問題，還有第3個問題，那就是攻擊者不修改數據，只是重復攻擊
比如在瀏覽器端通過用戶名/密碼驗證獲得簽名的Token被木馬竊取。即使用戶登出了系統，黑客還是可以利用竊取的Token模擬正常請求，而服務器端對此完全不知道， 因為JWT機制是無狀態的。
可以在Payload裏增加時間戳並且前後端都參與來解決：