一、前言
在如今，微服務架構越來越流行了，項目也越來越多采用前后端項目分離，一般在權限控制中采用JWT進行處理。
二、JWT介紹
JWT是一種認證協議是最后輸出為token,然后把token進行傳到客戶端，客戶端訪問api通過filter解析token,獲得jwt中的信息，進行判斷操作。
jwt分為三部分 ，header、payload
、Signature。 header是具有哈希算法、以及typ類型。
哈希算法可以采用SHA256等 ，哈希算法不是加密算法。它是值把一個值進行通過哈希碰撞生成一個加密的值，是不存在解密的，唯一解密的方式就是重復試值進行碰撞產生相同的值。
payload是值我們需要傳入的信息，一般不要進行敏感的信息。然后使用Base64編碼，Header也是使用Base64編碼
JWT 的最后一部分是 Signature ，這部分內容有三個部分，先是用 Base64 編碼的 header 和 payload ，再用加密算法加密一下，加密的時候要放進去一個 Secret ，這個相當於是一個密碼，這個密碼秘密地存儲在服務端。
三、安全問題
1.如果其他用戶獲得我們電腦上的token,那么他們就能模仿真實用戶進行操作（黑客監控電腦，獲得網站發送的token,進行操作）？
對於敏感的api接口，需使用https 。https是在http超文本傳輸協議加入SSL層，它在網絡間通信是加密的，所以需要加密證書。
2.我們是否可以偽造用戶token進行訪問？
不可以，因為你無法使用服務器的簽名，就是你自己的密鑰簽名的信息服務器識別不了。
3.我們是否可以修改token中body的信息？
不能，修改了之后簽名信息就不正確，然后就無法驗證簽名，說明數據被修改了。
四. csdn中的http和https的一種回復
Question:app登錄后，服務端返回一個token，app存在客戶端，下次再打開app時，直接讀token，傳token到服務端做驗證，免去重新輸入用戶密碼的麻煩，這個token存儲在header里，目前看大多數app都是這樣做，但如果黑客抓包獲取到token，偽造http 請求，對服務器做操作，那豈不是很不安全。。。
Answer:這方法確實不好啊，不能只依賴於http的header里的東西來認證，太容易模仿。最簡單的方法可能就是走https，客戶端只要接受服務器端的簽名即可。
理解：簽名就是驗證信息的唯一性，如果中間人進行獲得token，那么無法進行公鑰簽名，服務器獲得token之后還要進行解密的，因此這個方法可以進行避免攻擊。
中間人如何抓包獲取局域網的http請求?
五、總結
對於敏感的api接口，需使用https 。https是在http超文本傳輸協議加入SSL層，它在網絡間通信是加密的，所以需要加密證書。
采用https 或者 代碼層面也可以做安全檢測，比如ip地址發生變化，MAC地址發生變化等等，可以要求重新登錄