1. 程式人生 > >JWT與Session的比較

JWT與Session的比較

如今,越來越多的專案開始採用JWT作為認證授權機制,那麼它和之前的Session究竟有什麼區別呢?今天就讓我們來了解一下。

JWT是什麼

定義

JSON Web Token(JWT)是一個開放標準(RFC 7519),它定義了一種緊湊和自包含的方式,用於在各方之間作為JSON物件安全地傳輸資訊。作為標準,它沒有提供技術實現,但是大部分的語言平臺都有按照它規定的內容提供了自己的技術實現,所以實際在用的時候,只要根據自己當前專案的技術平臺,到官網上選用合適的實現庫即可。

特點

使用JWT來傳輸資料,實際上傳輸的是一個字串,這個字串就是所謂的json web token字串。所以廣義上,JWT是一個標準的名稱;狹義上,JWT指的就是用來傳遞的那個token字串。這個串有兩個特點:

  1. 緊湊:指的是這個串很小,能通過url 引數,http 請求提交的資料以及http header的方式來傳遞;
  2. 自包含:這個串可以包含很多資訊,比如使用者的id、角色等,別人拿到這個串,就能拿到這些關鍵的業務資訊,從而避免再通過資料庫查詢等方式才能得到它們。

結構

它由三部分組成:header(頭部)、payload(載荷)、signature(簽名),以.進行分割。(這個字串本來是隻有一行的,此處分成3行,只是為了區分其結構)

  1. header用來宣告型別(typ)和演算法(alg)。
  2. payload一般存放一些不敏感的資訊,比如使用者名稱、許可權、角色等。
  3. signature則是將header
    payload對應的json結構進行base64url編碼之後得到的兩個串用英文句點號拼接起來,然後根據header裡面alg指定的簽名演算法生成出來的。

Session的區別

為什麼我們要把JWTSession做對比呢?因為我們主要在每一次請求的認證時會用JWT,在此之前我們都是用Session的。那這兩者的區別在哪兒呢?

本身的含義

看了前面的介紹,我們發現JWT這個字串其實本身就包含了關於使用者的資訊,比如使用者名稱、許可權、角色等。

Session傳遞的sessionId雖然是一個更簡單的字串,但它本身並沒有任何含義。

所以一般說來JWT的字串要比sessionId長,如果你在JWT

中儲存的資訊越長,那麼JWT本身也會越長。

Cookie的儲存容量是有限制的(通常為4KB),所以大家在使用的時候需要注意。

解析方法

JWT的header和payload其實是有json轉變過來的,而signature其實就是一個加密後的字串,因此解析起來較為簡單,不需要其他輔助的內容。

sessionId是伺服器儲存的使用者物件的標識,理論上需要一個額外的map才能找出當前使用者的資訊。

管理方法

JWT理論上用於無狀態的請求,因此其使用者管理也只是依賴本身而已。我們一般是在它的payload中加入過期時間,在不增加額外管理的情況下,它只有自動過期的方式。

Session因為它本就是儲存在伺服器端的,因此管理方案就有很多,而且大多都很成熟。

跨平臺

JWT本身就是基於json的,因此它是比較容易跨平臺的,可以從官網下載不同平臺的包,解析即可。

session的跨平臺可能就不那麼好做了,需要考慮的地方在於使用者資訊儲存的格式,ProtoBuf、json、xml等,管理的話可能就需要專門的統一登入平臺,這個就不展開了。

時效性

無狀態JWT一旦被生成,就不會再和服務端有任何瓜葛。一旦服務端中的相關資料更新,無狀態JWT中儲存的資料由於得不到更新,就變成了過期的資料。

session就不一樣了,sessionId本身就沒有太多含義,只需修改服務端中儲存的資料即可。

適用場景

JWT

JWT的最佳用途是一次性授權Token,這種場景下的Token的特性如下:

  • 有效期短
  • 只希望被使用一次

真實場景的例子——檔案託管服務,由兩部分組成:

  • Web 應用:這是一個可以被使用者登入並維持狀態的應用,使用者在應用中挑選想要下載的檔案。
  • 檔案下載服務:無狀態下載服務,只允許通過金鑰下載。

如何把JWT用在這個場景中呢?

  1. 使用者登入到 Web 應用中,挑選好想要下載的檔案,點選下載。
  2. 認證服務頒發包含下載資訊的、具有較短過期時間的JWT。JWT中包含的資訊可以是這樣的:
{
    "file": "/books/我這一輩子.pdf",
    "exp": 1500719759621
}
  1. 使用 JWT 從檔案下載服務下載檔案。

Session

Session比較適用於Web應用的會話管理,其特點一般是:

  • 許可權多,如果用JWT則其長度會很長,很有可能突破Cookie的儲存限制。
  • 基本資訊容易變動。如果是一般的後臺管理系統,肯定會涉及到人員的變化,那麼其許可權也會相應變化,如果使用JWT,那就需要伺服器端進行主動失效,這樣就將原本無狀態的JWT變成有狀態,改變了其本意。

總結

我們使用JWT,並不是說看到它新就用,而應該考慮其適用場景,如果需要進行管理,可以考慮使用Session,畢竟其方案更加成熟。如果大家有什麼新發現想和作者探討的,歡迎在下方留言。

有興趣的話可以關注我的公眾號,說不定會有意外的驚喜。