JSON Web Token - 在Web應用間安全地傳遞資訊

來源:互聯網
上載者:User

標籤:小知識   attr   nbsp   lan   node   完整   stream   from   meta   

JSON Web Token(JWT)是一個非常輕巧的規範。這個規範允許我們使用JWT在使用者和伺服器之間傳遞安全可靠的資訊。

讓我們來假想一下一個情境。在A使用者關注了B使用者的時候,系統發郵件給B使用者,並且附有一個連結“點此關注A使用者”。連結的地址可以是這樣的

1 https://your.awesome-app.com/make-friend/?from_user=B&target_user=A

上面的URL主要通過URL來描述這個當然這樣做有一個弊端,那就是要求使用者B使用者是一定要先登入的。可不可以簡化這個流程,讓B使用者不用登入就可以完成這個操作。JWT就允許我們做到這點。

 

JWT的組成

一個JWT實際上就是一個字串,它由三部分組成,頭部載荷簽名

載荷(Payload)

我們先將上面的添加好友的操作描述成一個JSON對象。其中添加了一些其他的資訊,協助今後收到這個JWT的伺服器理解這個JWT。

123456789 {"iss": "John Wu JWT","iat": 1441593502,"exp": 1441594722,"aud": "www.example.com","sub": "[email protected]","from_user": "B","target_user": "A"}

這裡面的前五個欄位都是由JWT的標準所定義的。

  • iss: 該JWT的簽發者
  • sub: 該JWT所面向的使用者
  • aud: 接收該JWT的一方
  • exp(expires): 什麼時候到期,這裡是一個Unix時間戳記
  • iat(issued at): 在什麼時候簽發的

這些定義都可以在標準中找到。

將上面的JSON對象進行[base64編碼]可以得到下面的字串。這個字串我們將它稱作JWT的Payload(載荷)。

1 eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

如果你使用Node.js,可以用Node.js的包base64url來得到這個字串。

1234567 var base64url = require(‘base64url‘)var header = {"from_user": "B","target_user": "A"}console.log(base64url(JSON.stringify(header)))// 輸出:eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

小知識:Base64是一種編碼,也就是說,它是可以被翻譯回原來的樣子來的。它並不是一種加密過程。

頭部(Header)

JWT還需要一個頭部,頭部用於描述關於該JWT的最基本的資訊,例如其類型以及簽名所用的演算法等。這也可以被表示成一個JSON對象。

1234 {"typ": "JWT","alg": "HS256"}

在這裡,我們說明了這是一個JWT,並且我們所用的簽名演算法(後面會提到)是HS256演算法。

對它也要進行Base64編碼,之後的字串就成了JWT的Header(頭部)。

1 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
簽名(簽名)

將上面的兩個編碼後的字串都用句號.串連在一起(頭部在前),就形成了

1 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

這一部分的過程在node-jws的源碼中有體現

最後,我們將上面拼接完的字串用HS256演算法進行加密。在加密的時候,我們還需要提供一個密鑰(secret)。如果我們用mystar作為密鑰的話,那麼就可以得到我們加密後的內容

1 rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

這一部分又叫做簽名

 

最後將這一部分簽名也拼接在被簽名的字串後面,我們就得到了完整的JWT

1 eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

於是,我們就可以將郵件中的URL改成

1 https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

這樣就可以安全地完成添加好友的操作了!

且慢,我們一定會有一些問題:

  1. 簽名的目的是什嗎?
  2. Base64是一種編碼,是可逆的,那麼我的資訊不就被暴露了嗎?

讓我逐一為你說明。

簽名的目的

最後一步簽名的過程,實際上是對頭部以及載荷內容進行簽名。一般而言,密碼編譯演算法對於不同的輸入產生的輸出總是不一樣的。對於兩個不同的輸入,產生同樣的輸出的機率極其地小(有可能比我成世界首富的機率還小)。所以,我們就把“不一樣的輸入產生不一樣的輸出”當做必然事件來看待吧。

所以,如果有人對頭部以及載荷的內容解碼之後進行修改,再進行編碼的話,那麼新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且,如果不知道伺服器加密的時候用的密鑰的話,得出來的簽名也一定會是不一樣的。

 

伺服器應用在接受到JWT後,會首先對頭部和載荷的內容用同一演算法再次簽名。那麼伺服器應用是怎麼知道我們用的是哪一種演算法呢?別忘了,我們在JWT的頭部中已經用alg欄位指明了我們的密碼編譯演算法了。

如果伺服器應用對頭部和載荷再次以同樣方法簽名之後發現,自己計算出來的簽名和接受到的簽名不一樣,那麼就說明這個Token的內容被別人動過的,我們應該拒絕這個Token,返回一個HTTP 401 Unauthorized響應。

資訊會暴露?

是的。

所以,在JWT中,不應該在載荷裡面加入任何敏感的資料。在上面的例子中,我們傳輸的是使用者的User ID。這個值實際上不是什麼敏感內容,一般情況下被知道也是安全的。

但是像密碼這樣的內容就不能被放在JWT中了。如果將使用者的密碼放在了JWT中,那麼懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。

JWT的適用情境

我們可以看到,JWT適合用於向Web應用傳遞一些非敏感資訊。例如在上面提到的完成加好友的操作,還有諸如下訂單的操作等等。

JSON Web Token - 在Web應用間安全地傳遞資訊

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.