概述
若是各位不瞭解 JWT，沒關係張，它並不可怕。前端
JSON Web Token（JWT）是一個很是輕巧的規範。這個規範容許咱們使用JWT在用戶和服務器之間傳遞安全可靠的信息。算法
讓咱們來假想一下一個場景。在A用戶關注了B用戶的時候，系統發郵件給B用戶，而且附有一個連接「點此關注A用戶」。連接的地址能夠是這樣的json
https://www.xxxx.com/make-friend/?from_user=B&target_user=A
組成
一個JWT實際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。後端
載荷（Payload）
咱們先將上面的添加好友的操做描述成一個JSON對象。其中添加了一些其餘的信息，幫助從此收到這個JWT的服務器理解這個JWT。安全
{
"iss": "LiuzhichaoJWT",
"iat": int(time.time()),
"exp": expire_time,
"aud": "luffy",
"sub": "target@example.com",
"from_user": "B",
"target_user": "A"
}
這裏面的前五個字段都是由JWT的標準所定義的。服務器
-
iss: 該JWT的簽發者cookie -
sub: 該JWT所面向的用戶session -
aud: 接收該JWT的一方前後端分離 -
exp(expires): 何時過時，這裏是一個Unix時間戳分佈式 -
iat(issued at): 在何時簽發的
這些定義均可以在標準中找到。
將上面的JSON對象進行[base64編碼]能夠獲得下面的字符串。這個字符串咱們將它稱做JWT的Payload（載荷）。
eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9
# 載荷 expire_time = int(time.time() + 10) payload = { "iss": "LiuzhichaoJWT", "iat": int(time.time()), "exp": expire_time, "aud": "luffy", "sub": "target@example.com", "from_user": "B", "target_user": "A" } json_payload = base64.urlsafe_b64encode(json.dumps(payload).encode("utf-8")) print(json_payload)
頭部（Header)
JWT還須要一個頭部，頭部用於描述關於該JWT的最基本的信息，例如其類型以及簽名所用的算法等。這也能夠被表示成一個JSON對象。
{ "typ": "JWT", "alg": "HS256" }
在這裏，咱們說明了這是一個JWT，而且咱們所用的簽名算法（後面會提到）是HS256算法。
對它也要進行Base64編碼，以後的字符串就成了JWT的Header（頭部）。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
import json import base64 headers = { "typ": "JWT", "alg": "HS256" } base64.urlsafe_b64encode(json.dumps(headers).encode("utf-8")).replace(b'=', b'')
簽名（簽名)
將上面的兩個編碼後的字符串都用句號 .鏈接在一塊兒（頭部在前），就造成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9
最後，咱們將上面拼接完的字符串用HS256算法進行加密。在加密的時候，咱們還須要提供一個密鑰（secret）。若是咱們用 `liuzhichao` 做爲密鑰的話，那麼就能夠獲得咱們加密後的內容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
# 密鑰 key = "liuzhichao" string = b".".join([header_string, json_payload]) # 簽名 sign = base64.urlsafe_b64encode(hmac.new(key.encode("utf-8"), string, hashlib.sha256).digest()) print(sign)
這一部分又叫作簽名。
最後將這一部分簽名也拼接在被簽名的字符串後面，咱們就獲得了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
因而，咱們就能夠將郵件中的URL改爲
https://www.xxx.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
這樣就能夠安全地完成關注好友的操做了！
且慢，這裏你們思考下有什麼問題沒有：
- 簽名的目的是什麼？
- Base64是一種編碼，是可逆的，那麼信息不就被暴露了嗎？
簽名的目的
最後一步簽名的過程，其實是對頭部以及載荷內容進行簽名。通常而言，加密算法對於不一樣的輸入產生的輸出老是不同的。對於兩個不一樣的輸入，產生一樣的輸出的機率極其地小（有可能比我成世界首富的機率還小）。因此，咱們就把「不同的輸入產生不同的輸出」當作必然事件來看待吧。
因此，若是有人對頭部以及載荷的內容解碼以後進行修改，再進行編碼的話，那麼新的頭部和載荷的簽名和以前的簽名就將是不同的。並且，若是不知道服務器加密的時候用的密鑰的話，得出來的簽名也必定會是不同的。
服務器應用在接受到JWT後，會首先對頭部和載荷的內容用同一算法再次簽名。那麼服務器應用是怎麼知道咱們用的是哪種算法呢？別忘了，咱們在JWT的頭部中已經用 alg字段指明瞭咱們的加密算法了(並且 JWT 在後端建立以後,只留下加密方式,不會保存.在傳給前端)。
若是服務器應用對頭部和載荷再次以一樣方法簽名以後發現，本身計算出來的簽名和接受到的簽名不同，那麼就說明這個Token的內容被別人動過的，咱們應該拒絕這個Token，返回一個HTTP 401 Unauthorized響應。
缺點
1.信息容易暴露
在JWT中，不該該在載荷裏面加入任何敏感的數據。在上面的例子中，咱們傳輸的是用戶的User ID。這個值實際上不是什麼敏感內容，通常狀況下被知道也是安全的。可是像密碼這樣的內容就不能被放在JWT中了。若是將用戶的密碼放在了JWT中，那麼懷有惡意的第三方經過Base64解碼就能很快地知道你的密碼了。
2.註銷問題 :
與傳統的cookie+session相比較,用戶想要主動註銷,那麼在服務端中清除便可.
可是因爲 JWT 是無狀態的,服務端經過計算進行校驗,是不進行存儲的,即便是在客戶端清除,服務端仍是在有效期內的.
解決 :
1).由於jwt是放在客戶端的cookie中,清除cookie便可.
2).清空或者修改服務器中的用戶對應的secret,這樣在用戶註銷後,可是因爲secret不存在或者改變,則沒法完成校驗.
爲何用 jwt
爲何用jwt而不是用session,與session相比較,jwt的優勢 :
1).適合分佈式,先後端分離.優點在於服務端不存儲任何會話,用戶傳遞的信息經過token解析---分佈式
(就像 阿里與菜鳥驛站的關係)