文章目錄

• • 一、JWT是什么
  • 二、跨域認證問題
  • 三、JWT原理
  • 四、JWT數據結構
  • • 1、header(頭部)
    • 2、Payload(負載)
    • 3、Signature
  • 五、JWT是如何工作的

一、JWT是什么

JSON Web Token (JWT)是一個開放標準(RFC 7519)，它定義了一種緊湊的、自包含的方式，用于作為JSON對象在各方之間安全地傳輸信息。該信息可以被驗證和信任，因為它是數字簽名的。

二、跨域認證問題

互聯網服務離不開用戶認證，一般流程如下：

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

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

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

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

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

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

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

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

三、JWT原理

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

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

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

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

四、JWT數據結構

實際返回給前端JWT數據結構是這樣

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6I kpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7Hg Q

是一個很長的字符串，中間以(.)分割。注意JWT沒有換行的

JWT三部分如下：

Header（頭部） Payload（負載） Signature（簽名）

1、header(頭部)

header典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256或者RSA等等）。

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

然后，用Base64對這個JSON編碼就得到JWT的第一部分

2、Payload(負載)

JWT的第二部分是payload，它包含聲明（要求）。聲明是關于實體(通常是用戶)和其他數據的聲明。聲明有三種類型: registered, public 和private

• Registered claims : 這里有一組預定義的聲明，它們不是強制的，但是推薦。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
• Public claims : 可以隨意定義。
• Private claims : 用于在同意使用它們的各方之間共享信息，并且不是注冊的或公開的聲明。
  官方給了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的payload或header中放置敏感信息，除非它們是加密的。

3、Signature

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

首先，需要指定一個密鑰（secret）。這個密鑰只有服務器才知道，不能泄露給用戶。然后，使用 Header 里面指定的簽名算法（默認是 HMAC SHA256），按照下面的公式產生簽名。
看一張官網的圖就明白了：

五、JWT是如何工作的

在認證的時候，當用戶用他們的憑證成功登錄以后，一個JSON Web Token將會被返回。此后，token就是用戶憑證了，你必須非常小心以防止出現安全問題。一般而言，你保存令牌的時候不應該超過你所需要它的時間。

無論何時用戶想要訪問受保護的路由或者資源的時候，用戶代理（通常是瀏覽器）都應該帶上JWT，典型的，通常放在Authorization header中，用Bearer schema。

header應該看起來是這樣的：

Authorization: Bearer

服務器上的受保護的路由將會檢查Authorization header中的JWT是否有效，如果有效，則用戶可以訪問受保護的資源。如果JWT包含足夠多的必需的數據，那么就可以減少對某些操作的數據庫查詢的需要，盡管可能并不總是如此。

如果token是在授權頭（Authorization header）中發送的，那么跨源資源共享(CORS)將不會成為問題，因為它不使用cookie。

鳴謝：
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html https://www.cnblogs.com/cjsblog/p/9277677.html

總結

以上是生活随笔為你收集整理的JWT(JSON Web Token)简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。