Hi，這里是桑小榆。上篇文章中，我們一起探討了 OAuth 協議的原理以及授權認證流程，本次我們一起探討 jwt 令牌作為授權協議的傳輸介質。

OAuth協議規范了幾個參與角色的授權標準，安全可控的授予第三方應用，第三方應用獲取到用戶授予的權限之后，與資源服務器進行交互。那么在進行交互的時候，必然需要一種傳輸介質，且需要攜帶用戶身份的信息，使得服務器之間能夠識別并認證。這個傳輸的介質就是我們此次探討的 jwt。

jwt，全稱 Json Web Token，也就是日常說的 token 令牌。它是通過數字簽名的方式，以 json 對象為載體，在不同服務終端之間安全傳輸信息。

我們可以看到jwt的定義，它具有和 json 一樣的特性，非常輕量的傳輸方式，且易于人閱讀和編寫，利于機器的解析和生成。

它像我們的居民身份證一樣，一旦相關權威部門識別你是合法公民且會頒發一個適用于本土的證件，通過這個證件可以任意出入需要出示證件的地方。那么jwt也是一樣，在服務器認證你的合法用戶身份之后，會生成一個json對象，發送給用戶，例如：

{"姓名":?"桑小榆","角色":?"管理員","到期時間":?"2022年10月1日?10點10分"
}

之后，用戶每需要與服務器通訊的時候，攜帶具有身份信息的json。服務器完全只需要驗證用戶攜帶的身份信息。

當然，用戶信息不會以明文的方式攜帶，不然很容易被不法分子截獲進行篡改，那這個令牌就變得無意義了。但凡頒發任何具備流通的信息，都需要具備防偽標識。例如身份證，系統架構師資格證，人民幣等都具備復雜的防偽信息。

那 jwt 在生成的時候，通常是加上簽名來防止篡改的。形成一個標準的 jwt 格式如下：

▲圖/?jwt解析組成部分

我們可以看到左邊生生簽名之后的 jwt 格式是很長得一串字符組成，中間由（.）隔開分成三部分。

我們看到右邊解析之后，是jwt的組成格式。

Header?????頭部
Payload????載荷
Signature??簽名以上組成jwt格式為：Header.Payload.Signature

那么我們將依次探討這三部分。

Header頭部

header部分是一個json對象，描述jwt的一些元數據，也就是屬性信息。通常格式如下：

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

上面的代碼中，alg屬性表示采用簽名的算法（algorithm），默認是 hmac sha256,寫成 hs256。這里通常有幾種比較常用的簽名算法rs256，hs256，base64。

rs256（帶有sha-256的 rsa 簽名）是一種非對稱算法，它使用公鑰/私鑰對：身份提供者擁有用于生成簽名的私鑰（秘密）密鑰，而 jwt 的消費者獲得公鑰驗證簽名。由于與私鑰相反，公鑰不需要保持安全，因此大多數身份提供者都可以讓消費者輕松獲取和使用（通常通過元數據 url）。

hs256（帶有 sha-256 的hmac）涉及散列函數和一個密鑰的組合，該密鑰在兩方之間共享，用于生成用作簽名的散列。由于生成簽名和驗證簽名都使用相同的密鑰，因此必須注意確保密鑰不被泄露。

typ屬性表示這個令牌（token）的類型（type），jwt 令牌統一寫為jwt。

最后，將上面的 json 對象使用 base64url?算法轉成字符串。

Payload?載荷

payload 部分也是一個 json 對象，用來存放實際需要傳遞的數據，通常包含一些簽發的信息。jwt 規定了7個官方字段，供選用。

iss?(issuer):?jwt簽發者.sub?(subject):?jwt所面向的用戶.aud?(audience):?接收jwt的一方.exp?(expiration?time):?jwt的過期時間，這個過期時間必須要大于簽發時間.nbf?(Not?Before):?定義在什么時間之前，該jwt都是不可用的.iat?(Issued?At):?jwt的簽發時間.jti?(JWT?ID):?jwt的唯一身份標識，主要用來作為一次性token,從而回避重放攻擊.

當然除了官方定義的七種之外，還可以自己定義一些私有字段。例如上圖 jwt 格式中的 payload 格式，就是是自定義了一些私有字段。

{"sub":?"1234567890","name":?"桑小榆呀","iat":?1516239022

注意，jwt 默認是不加密的，任何人都可以讀到，所以不要把私密信息放在這個部分。所以，payload 部分要使用 base64url 算法轉成字符串。

Signature?簽名

signature 部分是對前header和payload的簽名，防止數據篡改。

首先，需要指定一個256位的密鑰（secret）。這個密鑰只有服務器才知道，不能泄露給用戶。然后，使用 header 里面指定的簽名算法（默認是 hmac?sha256），按照下面的公式產生簽名。

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

算出簽名以后，把 header、payload、signature 三個部分拼成一個字符串，每個部分之間用點（.）分隔，就可以返回給用戶。

Base64Url 算法

我們在上面的文章中也多次提到，header和payload部分需要使用base64url算法。base64url算法跟base64算法基本類似，但也有一些不同。

jwt作為一個token令牌，有些使用場景可能會用到url，例如 https://jwt.io/?token=xxx。加密流程首先會對url的明文進行加密，其次在base64加密的基礎上，會對url里面特殊字符進行處理：=被省略、+替換成-，/替換成_?。這就是base64url加密算法。

JWT 使用

我們探討完了 jwt 的組成之后，回歸到使用上。在身份驗證中，客戶端使用身份憑據成功登錄時，將返回一個 Token 令牌。由于令牌是憑據，因此必須非常小心以防止出現安全問題。通常情況下不應該將令牌保留超過所需的時間。

雖然我們可以將Token存儲在Cookie和localStorage當中，進行自動發送。但會缺乏安全性，和跨域的問題。更好的做法是在authorization標頭中使用bearer模式。標頭的內容應如下所示：

Authorization:?Bearer?<token>

如果令牌在authorization標頭中發送，則跨域資源共享 (CORS) 不會成為問題，因為它不使用 cookie。配合https傳輸也能大大提高了安全性。

▲圖/?jwt簡易授權流程

JWT 特點

最后我們總結 jwt 的幾個特點：

1. ?jwt 默認是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次。

2. jwt 不加密的情況下，不能將秘密數據寫入 jwt 。

3. jwt 不僅可以用于認證，也可以用于交換信息。有效使用 jwt ，可以降低服務器查詢數據庫的次數。

4. jwt 的最大缺點是，由于服務器不保存 session 狀態，因此無法在使用過程中廢止某個 token，或者更改 token 的權限。也就是說，一旦 jwt 簽發了，在到期之前就會始終有效，除非服務器部署額外的邏輯。

5. jwt 本身包含了認證信息，一旦泄露，任何人都可以獲得該令牌的所有權限。為了減少盜用，jwt 的有效期應該設置得比較短。對于一些比較重要的權限，使用時應該再次對用戶進行認證。

6. 為了減少盜用，jwt 不應該使用 http 協議明碼傳輸，要使用 https 協議傳輸。

我們一起探討完了 jwt 相關知識。下篇我們將以代碼實操的方式來演示 jwt 的生成以及使用，并且配合 oidc 一套標準的授權流程。

👇?更多有趣內容，請多關注！👇