token的主要用法?


一、跨域認證的問題

互聯網服務離不開用戶認證。一般流程是下面這樣。

1、用戶向服務器發送用戶名和密碼。

2、服務器驗證通過后,在當前對話(session)里面保存相關數據,比如用戶角色、登錄時間等等。

3、服務器向用戶返回一個 session_id,寫入用戶的 Cookie。

4、用戶隨后的每一次請求,都會通過 Cookie,將 session_id 傳回服務器。

5、服務器收到 session_id,找到前期保存的數據,由此得知用戶的身份。

這種模式的問題在於,擴展性(scaling)不好。單機當然沒有問題,如果是服務器集群,或者是跨域的服務導向架構,就要求 session 數據共享,每台服務器都能夠讀取 session。

舉例來說,A 網站和 B 網站是同一家公司的關聯服務。現在要求,用戶只要在其中一個網站登錄,再訪問另一個網站就會自動登錄,請問怎么實現?

一種解決方案是 session 數據持久化,寫入數據庫或別的持久層。各種服務收到請求后,都向持久層請求數據。這種方案的優點是架構清晰,缺點是工程量比較大。另外,持久層萬一掛了,就會單點失敗。

另一種方案是服務器索性不保存 session 數據了,所有數據都保存在客戶端,每次請求都發回服務器。JWT 就是這種方案的一個代表。

二、JWT 的原理

JWT 的原理是,服務器認證以后,生成一個 JSON 對象,發回給用戶,就像下面這樣。

{ "姓名": "張三", "角色": "管理員", "到期時間": "2018年7月1日0點0分"}
 

以后,用戶與服務端通信的時候,都要發回這個 JSON 對象。服務器完全只靠這個對象認定用戶身份。為了防止用戶篡改數據,服務器在生成這個對象的時候,會加上簽名(詳見后文)。

服務器就不保存任何 session 數據了,也就是說,服務器變成無狀態了,從而比較容易實現擴展。

三、JWT 的數據結構

實際的 JWT 大概就像下面這樣。

它是一個很長的字符串,中間用點(.)分隔成三個部分。注意,JWT 內部是沒有換行的,這里只是為了便於展示,將它寫成了幾行。

JWT 的三個部分依次如下。

  • Header(頭部)

  • Payload(負載)

  • Signature(簽名)

寫成一行,就是下面的樣子。

Header.Payload.Signature
 

下面依次介紹這三個部分。

3.1 Header

Header 部分是一個 JSON 對象,描述 JWT 的元數據,通常是下面的樣子。

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

上面代碼中,alg屬性表示簽名的算法(algorithm),默認是 HMAC SHA256(寫成 HS256);typ屬性表示這個令×××(token)的類型(type),JWT 令×××統一寫為JWT

最后,將上面的 JSON 對象使用 Base64URL 算法(詳見后文)轉成字符串。

3.2 Payload

Payload 部分也是一個 JSON 對象,用來存放實際需要傳遞的數據。JWT 規定了7個官方字段,供選用。

  • iss (issuer):簽發人

  • exp (expiration time):過期時間

  • sub (subject):主題

  • aud (audience):受眾

  • nbf (Not Before):生效時間

  • iat (Issued At):簽發時間

  • jti (JWT ID):編號

除了官方字段,你還可以在這個部分定義私有字段,下面就是一個例子。

{ "sub": "1234567890", "name": "John Doe", "admin": true}
 

注意,JWT 默認是不加密的,任何人都可以讀到,所以不要把秘密信息放在這個部分。

這個 JSON 對象也要使用 Base64URL 算法轉成字符串。

3.3 Signature

Signature 部分是對前兩部分的簽名,防止數據篡改。

首先,需要指定一個密鑰(secret)。這個密鑰只有服務器才知道,不能泄露給用戶。然后,使用 Header 里面指定的簽名算法(默認是 HMAC SHA256),按照下面的公式產生簽名。

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

算出簽名以后,把 Header、Payload、Signature 三個部分拼成一個字符串,每個部分之間用"點"(.)分隔,就可以返回給用戶。

3.4 Base64URL

前面提到,Header 和 Payload 串型化的算法是 Base64URL。這個算法跟 Base64 算法基本類似,但有一些小的不同。

JWT 作為一個令×××(token),有些場合可能會放到 URL(比如 api.example.com/?token=xxx)。Base64 有三個字符+/=,在 URL 里面有特殊含義,所以要被替換掉:=被省略、+替換成-/替換成_ 。這就是 Base64URL 算法。

四、JWT 的使用方式

客戶端收到服務器返回的 JWT,可以儲存在 Cookie 里面,也可以儲存在 localStorage。

此后,客戶端每次與服務器通信,都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發送,但是這樣不能跨域,所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面。

Authorization: Bearer <token>
 

另一種做法是,跨域的時候,JWT 就放在 POST 請求的數據體里面。

五、JWT 的幾個特點

(1)JWT 默認是不加密,但也是可以加密的。生成原始 Token 以后,可以用密鑰再加密一次。

(2)JWT 不加密的情況下,不能將秘密數據寫入 JWT。

(3)JWT 不僅可以用於認證,也可以用於交換信息。有效使用 JWT,可以降低服務器查詢數據庫的次數。

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

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

(6)為了減少盜用,JWT 不應該使用 HTTP 協議明碼傳輸,要使用 HTTPS 協議傳輸。

六、參考鏈接

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM