BearerToken之JWT的介紹

時間 2019-11-05

標籤 bearertoken jwt 介紹简体版

原文原文鏈接

Bearer認證

HTTP提供了一套標準的身份驗證框架：服務器能夠用來針對客戶端的請求發送質詢(challenge)，客戶端根據質詢提供身份驗證憑證。質詢與應答的工做流程以下：服務器端向客戶端返回401（Unauthorized，未受權）狀態碼，並在WWW-Authenticate頭中添加如何進行驗證的信息，其中至少包含有一種質詢方式。而後客戶端能夠在請求中添加Authorization頭進行驗證，其Value爲身份驗證的憑證信息。html

在HTTP標準驗證方案中，咱們比較熟悉的是"Basic"和"Digest"，前者將用戶名密碼使用BASE64編碼後做爲驗證憑證，後者是Basic的升級版，更加安全，由於Basic是明文傳輸密碼信息，而Digest是加密後傳輸。在前文介紹的Cookie認證屬於Form認證，並不屬於HTTP標準驗證。web

本文要介紹的Bearer驗證也屬於HTTP協議標準驗證，它隨着OAuth協議而開始流行，詳細定義見： RFC 6570。算法

+--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

Bearer驗證中的憑證稱爲BEARER_TOKEN，或者是access_token，它的頒發和驗證徹底由咱們本身的應用程序來控制，而不依賴於系統和Web服務器，Bearer驗證的標準請求方式以下：json

Authorization: Bearer [BEARER_TOKEN]

JWT(JSON WEB TOKEN)

上面介紹的Bearer認證，其核心即是BEARER_TOKEN，而最流行的Token編碼方式即是：JSON WEB TOKEN。api

Json web token (JWT), 是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準[RFC 7519(https://tools.ietf.org/html/rfc7519)。該token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登陸（SSO）場景。JWT的聲明通常被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也能夠增長一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。
jwt主要包含如下三個內容：跨域

頭部 Header
載荷 Payload
簽名 Signature

Jwt Token包含了使用.分隔的三部分安全

{Header 頭部}.{Payload 負載}.{Signature 簽名}

Header 通常由兩個部分組成：服務器

alg是是所使用的hash算法，如：HMAC SHA256或RSA，typ是Token的類型，在這裏就是：JWT。網絡

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

而後使用Base64Url編碼成第一部分app

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>

載荷 Payload

這一部分是JWT主要的信息存儲部分，其中包含了許多種的聲明（claims）。

Claims的實體通常包含用戶和一些元數據，這些claims分紅三種類型：

reserved claims：預約義的一些聲明，並非強制的可是推薦，它們包括 iss (issuer), exp (expiration time), sub (subject),aud(audience) 等（這裏都使用三個字母的緣由是保證 JWT 的緊湊）。
public claims: 公有聲明，這個部分能夠隨便定義，可是要注意和 IANA JSON Web Token 衝突。
private claims: 私有聲明，這個部分是共享被認定信息中自定義部分。

一個簡單的Pyload能夠是這樣子的：

{
   "user_name": "admin", 
   "scope": [
       "read","write","del"
   ], 
   "organization": "admin", 
   "exp": 1531975621, 
   "authorities": [
       "ADMIN"
   ], 
   "jti": "23408d38-8cdc-4460-beac-24c76dc7629a", 
   "client_id": "webapp"
}

這部分一樣使用Base64Url編碼成第二部分

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>

簽名 Signature

Signature是用來驗證發送者的JWT的同時也能確保在期間不被篡改。

簽名哈希部分是對上面兩部分數據簽名，經過指定的算法生成哈希，以確保數據不會被篡改。
首先，須要指定一個密碼（secret）。該密碼僅僅爲保存在服務器中，而且不能向用戶公開。而後，使用標頭中指定的簽名算法（默認狀況下爲HMAC SHA256）根據如下公式生成簽名。

使用Base64編碼後的header和payload以及一個祕鑰，使用header中指定簽名算法進行簽名。

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

結果

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

base64UrlEncode

如前所述，JWT頭和有效載荷序列化的算法都用到了Base64URL。該算法和常見Base64算法相似，稍有差異。
做爲令牌的JWT能夠放在URL中（例如api.example/?token=xxx）。 Base64中用的三個字符是"+"，"/"和"="，因爲在URL中有特殊含義，所以Base64URL中對他們作了替換："="去掉，"+"用"-"替換，"/"用"_"替換，這就是Base64URL算法，很簡單把。