摘抄自: blog.leapoahead.com/2015/09/06/understanding-jwt/node
JSON Web Token(JWT)是一個很是輕巧的規範。這個規範容許咱們使用JWT在用戶和服務器之間傳遞安全可靠的信息。算法
讓咱們來假想一下場景。在A用戶關注了B用戶的時候,系統發郵件給B用戶,而且附有一個連接"點此關注A用戶"。鏈接的地址能夠是這樣的:安全
https:////your.awesome-app.com/make-friend/?from_user=B&target_user=A服務器
上面的URL主要經過URL來描述這個固然這樣作有一個弊端,那就是要求用戶B用戶是必定要先登陸的。可不能夠簡化這個流程,讓B用戶不用登陸就能夠完成這個操做。JWT就容許咱們作到這點。app
JWT的組成ui
一個JWT實際上就是一個字符串,它由三部分組成,頭部、載荷與簽名。編碼
載荷(Payload)加密
咱們先將上面的添加好友的操做描述成一個JSON對象。其中添加了一些其餘信息,幫助從此收到這個JWT的服務器理解這個JWT。url
{ "iss":"Vincent JWT", "iat":1441593502, "exp":1441594722, "aud":"www.example.com", "sub":"jrocket@example.com", "from_user":"B", "target_user":"A" }
這裏面的前五個字段都是由JWT的標準所定義的。翻譯
將上面的JSON對象進行[base64編碼]能夠獲得下面的字符串。這個字符串咱們將它稱做JWT的Payload(載荷)。
eyJpc3MiOiJKb2huIFd1IEpXVCIsI...
若是你使用Node.js,能夠用Node.js的包base64url來的到這個字符串。
var base64url = require('base64url') var header = { "from_user": "B", "target_user": "A" } console.log(base64url(JSON.stringify(header))) // 輸出: eyJpc3MiOiJKb2huIFd1IEpXVCIsI...
小知識:Base64是一種編碼,也就是說,它是能夠被翻譯回原來的樣子來的。它並非一種加密過程。
頭部(Header)
JWT還須要一個頭部,頭部用於描述關於該JWT的最基本的信息,例如其類型以及簽名所用的算法等。這也能夠被表示成一個JSON對象。
{ "typ":"JWT", "alg":"HS256" }
在這裏,咱們說明了這是一個JWT,而且咱們所用的簽名算法(後面會提到)是HS256算法。
對它也要進行Base64編碼,以後的字符串就成了JWT的Header(頭部)。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
簽名(簽名)
將上面的兩個編碼後的字符串都用句號.鏈接在一塊兒(頭部在前),就造成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBI
這一部分的過程在node-jws的源碼中有體現
最後,咱們將上面拼接完的字符串用HS256算法進行加密。在加密的時候,咱們還須要提供一個密鑰(secret)。若是咱們用mystar做爲密鑰的話,那麼就能夠獲得咱們加密後的內容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
這一部分又叫作簽名。
Header + Payload = signature(簽名)
最後將這一部分簽名也拼接在被簽名的字符串後面,咱們就獲得了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
因而咱們就能夠將郵箱中的URL改爲
這樣就能夠安全地完成添加好友的操做了!
且慢,咱們必定會有一些問題:
簽名的目的
最後一步簽名的過程,其實是對頭部以及載荷內容進行簽名。通常而言,加密算法對於不一樣的輸入產生的輸出老是不同的。對於兩個不一樣的輸入,產生一樣的輸出的機率極其地小(有可能比我成爲世界首富的機率還小)。因此,咱們就把"不同的輸入產生不同的輸出"看成必然事件來看吧。
因此,若是有人對頭部以及載荷的內容解碼以後進行修改,再進行編碼的話,那麼新的頭部和載荷的簽名和以前的簽名就將是不同的。並且若是不知道服務器加密的時候用的密鑰的話,得出來的簽名也必定會是不同的。
服務器應用在接受到JWT後,會首先對頭部和載荷的內容用同一算法再次簽名。那麼服務器應用是怎知道咱們用的是哪種算法呢?別忘了,咱們在JWT的頭部中已經用alg字段指明瞭咱們的加密算法了。
若是服務器應用對頭部和載荷再次以一樣方法簽名以後發現,本身計算出來的簽名和接受到的簽名不同,那麼就說明這個Token的內容被別人動過的,咱們應該拒絕這個Token,返回一個HTTP 401 Unauthorized響應。
信息會暴露?
是的。
因此,在JWT中,不該該在載荷裏面加入任何敏感的數據。在上面的例子中,咱們傳輸的是用戶的User ID。這個值實際上不是什麼敏感內容,通常狀況下被知道也是安全的。
可是像密碼這樣的內容就不能被放在JWT中了。若是將用戶的密碼放在了JWT中,那麼懷有惡意的第三方經過Base64解碼就能很快地知道你的密碼了。
JWT的適用場景
咱們能夠看到,JWT適合用於向Web應用傳遞一些非敏感信息。例如在上面提到的完成加好友的操做,還有諸以下訂單的操做等等。
其實JWT還常常用於設計用戶認證和受權系統,甚至實現Web應用的單點登陸。