BearerToken之JWT的介紹

Bearer認(rèn)證

HTTP提供了一套標(biāo)準(zhǔn)的身份驗(yàn)證框架：服務(wù)器可以用來(lái)針對(duì)客戶端的請(qǐng)求發(fā)送質(zhì)詢(challenge)，客戶端根據(jù)質(zhì)詢提供身份驗(yàn)證憑證。質(zhì)詢與應(yīng)答的工作流程如下：服務(wù)器端向客戶端返回401（Unauthorized，未授權(quán)）狀態(tài)碼，并在WWW-Authenticate頭中添加如何進(jìn)行驗(yàn)證的信息，其中至少包含有一種質(zhì)詢方式。然后客戶端可以在請(qǐng)求中添加Authorization頭進(jìn)行驗(yàn)證，其Value為身份驗(yàn)證的憑證信息。

在HTTP標(biāo)準(zhǔn)驗(yàn)證方案中，我們比較熟悉的是"Basic"和"Digest"，前者將用戶名密碼使用BASE64編碼后作為驗(yàn)證憑證，后者是Basic的升級(jí)版，更加安全，因?yàn)锽asic是明文傳輸密碼信息，而Digest是加密后傳輸。在前文介紹的Cookie認(rèn)證屬于Form認(rèn)證，并不屬于HTTP標(biāo)準(zhǔn)驗(yàn)證。

本文要介紹的Bearer驗(yàn)證也屬于HTTP協(xié)議標(biāo)準(zhǔn)驗(yàn)證，它隨著OAuth協(xié)議而開始流行，詳細(xì)定義見： 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驗(yàn)證中的憑證稱為BEARER_TOKEN，或者是access_token，它的頒發(fā)和驗(yàn)證完全由我們自己的應(yīng)用程序來(lái)控制，而不依賴于系統(tǒng)和Web服務(wù)器，Bearer驗(yàn)證的標(biāo)準(zhǔn)請(qǐng)求方式如下：

Authorization: Bearer [BEARER_TOKEN]

JWT(JSON WEB TOKEN)

上面介紹的Bearer認(rèn)證，其核心便是BEARER_TOKEN，而最流行的Token編碼方式便是：JSON WEB TOKEN。

Json web token (JWT), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標(biāo)準(zhǔn)[RFC 7519(https://tools.ietf.org/html/rfc7519)。該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景。JWT的聲明一般被用來(lái)在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。
jwt主要包含以下三個(gè)內(nèi)容：

頭部 Header
載荷 Payload
簽名 Signature

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

{Header 頭部}.{Payload 負(fù)載}.{Signature 簽名}

Header 一般由兩個(gè)部分組成：

alg
typ

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

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

然后使用Base64Url編碼成第一部分

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>

載荷 Payload

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

Claims的實(shí)體一般包含用戶和一些元數(shù)據(jù)，這些claims分成三種類型：

reserved claims：預(yù)定義的一些聲明，并不是強(qiáng)制的但是推薦，它們包括 iss (issuer), exp (expiration time), sub (subject),aud(audience) 等（這里都使用三個(gè)字母的原因是保證 JWT 的緊湊）。
public claims: 公有聲明，這個(gè)部分可以隨便定義，但是要注意和 IANA JSON Web Token 沖突。
private claims: 私有聲明，這個(gè)部分是共享被認(rèn)定信息中自定義部分。

一個(gè)簡(jiǎn)單的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是用來(lái)驗(yàn)證發(fā)送者的JWT的同時(shí)也能確保在期間不被篡改。

簽名哈希部分是對(duì)上面兩部分?jǐn)?shù)據(jù)簽名，通過指定的算法生成哈希，以確保數(shù)據(jù)不會(huì)被篡改。
首先，需要指定一個(gè)密碼（secret）。該密碼僅僅為保存在服務(wù)器中，并且不能向用戶公開。然后，使用標(biāo)頭中指定的簽名算法（默認(rèn)情況下為HMAC SHA256）根據(jù)以下公式生成簽名。

使用Base64編碼后的header和payload以及一個(gè)秘鑰，使用header中指定簽名算法進(jìn)行簽名。

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

結(jié)果

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

base64UrlEncode

如前所述，JWT頭和有效載荷序列化的算法都用到了Base64URL。該算法和常見Base64算法類似，稍有差別。
作為令牌的JWT可以放在URL中（例如api.example/?token=xxx）。 Base64中用的三個(gè)字符是"+"，"/"和"="，由于在URL中有特殊含義，因此Base64URL中對(duì)他們做了替換："="去掉，"+"用"-"替換，"/"用"_"替換，這就是Base64URL算法，很簡(jiǎn)單把。

JWT的工作過程

客戶端接收服務(wù)器返回的JWT，將其存儲(chǔ)在Cookie或localStorage中。

此后，客戶端將在與服務(wù)器交互中都會(huì)帶JWT。如果將它存儲(chǔ)在Cookie中，就可以自動(dòng)發(fā)送，但是不會(huì)跨域，因此一般是將它放入HTTP請(qǐng)求的Header Authorization字段中。

Authorization: Bearer JWT_TOKEN

當(dāng)跨域時(shí)，也可以將JWT被放置于POST請(qǐng)求的數(shù)據(jù)主體中。

使用JWT具有如下好處

通用：因?yàn)閖son的通用性，所以JWT是可以進(jìn)行跨語(yǔ)言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語(yǔ)言都可以使用。
緊湊：JWT的構(gòu)成非常簡(jiǎn)單，字節(jié)占用很小，可以通過 GET、POST 等放在 HTTP 的 header 中，非常便于傳輸。
擴(kuò)展：JWT是自我包涵的，包含了必要的所有信息，不需要在服務(wù)端保存會(huì)話信息, 非常易于應(yīng)用的擴(kuò)展。

posted @ 2019-07-25 20:03 張占嶺閱讀(22272) 評(píng)論(0) 收藏舉報(bào)

刷新頁(yè)面返回頂部