Skip to content
On this page

JWT 身份驗證機制

簡單說

「JWT」就是 用戶端 請求資源的通行證。

流程圖解

出處

說明

JWT (JSON WEB TOKEN) 基於 RFC 7519 規範,定義了一種 json object 透過加密技術產生的「簽章」, 服務端 與 客戶端 藉由這個「簽章」身份驗證與取得信任。

服務端 在驗證 用戶端 後,會發予一個「JWT」token。 用戶端 在與 服務端 請求任何資源時,都需要帶上這個「JWT」token,供 服務端 做身份的驗證,只要「有效」就可以獲取資源。

技術

JWT 是由 . 將字串分割為三個部分 xxxxx.yyyyy.zzzzz :

  • Header 聲明 json

    • JWT 解密的演算法
    • 簽章類型
      json
      {
      	alg: 'HS256',
      	type: 'JWT'
      }
      
  • Payload 傳遞資料 json

    json
    {
    	exp: '過期時間',
    	iat: 'JWT 簽發時間',
    	// 簽章要傳遞的資料...
    	// role: '權限角色'
    }
    
  • Verify Signature 簽章驗證

    說明創建簽章的方式,必須由 header 加上 . 加上 payload 加上 secret ,再使用指定的演算法來加密,以下面的例子就是使用 HMAC SHA256 演算法創建 JWT 的。

    json
    HMACSHA256(
      base64UrlEncode(header) + "." +
      base64UrlEncode(payload),
      secret)
    

    主要可以辨視 JWT 有沒有被修改過,可以驗證 JWT 是否合法。

流程

  • 客戶端 登入成功, 服務端 發送「JWT」

  • 客戶端 存放「JWT」

  • 客戶端 向 服務端 請求資源時,在 header 標頭寫上 JWT

    jsx
    Authorization: <Bearer> <JWT TOKEN>
    
  • 服務端 驗證 header 標頭 JWT

    • 成功: 返回「請求資源」
    • 失敗: 通知「驗證失敗」

為什麼要加 Bearer ?

HTTP 認證標頭「Authorization」的寫法,必須要在 token 前加上 type,基於 RCF6750 規範,而JWT 是搭配 Bearer 型態。

好處

  • 無狀態 JWT 不在 服務端 儲存數據。
  • 廣展性佳 當 服務端 分布式部署情況下,不需要像 session 方式,做多機數據共享。

壞處

  • 安全性 不可放敏感資料在 JWT Token。
  • 一次性 當 payload 資料修改,就必須重簽章 JWT Token。

Reference