基於jwt的token驗證

一、什么是JWT

Json web token (JWT), 是為了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標准（(RFC 7519).
該token被設計為緊湊且安全的，特別適用於分布式站點的單點登錄（SSO）場景。
JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。

二、JWT的組成

1、JWT生成編碼后的樣子

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.UQmqAUhUrpDVV2ST7mZKyLTomVfg7sYkEjmdDI5XF8Q

2、JWT由三部分構成

第一部分我們稱它為頭部（header),第二部分我們稱其為載荷（payload, 類似於飛機上承載的物品)，第三部分是簽證（signature).

header

jwt的頭部承載兩部分信息：

• 聲明類型，這里是jwt
• 聲明加密的算法 通常直接使用 HMAC SHA256

完整的頭部就像下面這樣的JSON：

{
  'typ': 'JWT',
  'alg': 'HS256'
}
然后將頭部進行base64加密（該加密是可以對稱解密的),構成了第一部分

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

playload

載荷就是存放有效信息的地方。這個名字像是特指飛機上承載的貨品，這些有效信息包含三個部分

• 標准中注冊的聲明
• 公共的聲明
• 私有的聲明

標准中注冊的聲明 (建議但不強制使用) ：

• iss: jwt簽發者
• sub: jwt所面向的用戶
• aud: 接收jwt的一方
• exp: jwt的過期時間，這個過期時間必須要大於簽發時間
• nbf: 定義在什么時間之前，該jwt都是不可用的.
• iat: jwt的簽發時間
• jti: jwt的唯一身份標識，主要用來作為一次性token,從而回避重放攻擊。

公共的聲明 ：
公共的聲明可以添加任何的信息，一般添加用戶的相關信息或其他業務需要的必要信息.但不建議添加敏感信息，因為該部分在客戶端可解密.

私有的聲明 ：

私有聲明是提供者和消費者所共同定義的聲明，一般不建議存放敏感信息，因為base64是對稱解密的，意味着該部分信息可以歸類為明文信息。

定義一個payload:

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

然后將其進行base64加密，得到Jwt的第二部分

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

signature

jwt的第三部分是一個簽證信息，這個簽證信息由三部分組成：

• header (base64后的)
• payload (base64后的)
• secret

這個部分需要base64加密后的header和base64加密后的payload使用.連接組成的字符串(頭部在前)，然后通過header中聲明的加密方式進行加鹽secret組合加密，然后就構成了jwt的第三部分。

UQmqAUhUrpDVV2ST7mZKyLTomVfg7sYkEjmdDI5XF8Q

密鑰secret是保存在服務端的，服務端會根據這個密鑰進行生成token和驗證，所以需要保護好。

3、簽名的目的

　　最后一步簽名的過程，實際上是對頭部以及載荷內容進行簽名。一般而言，加密算法對於不同的輸入產生的輸出總是不一樣的。對於兩個不同的輸入，產生同樣的輸出的概率極其地小（有可能比我成世界首富的概率還小）。所以，我們就把“不一樣的輸入產生不一樣的輸出”當做必然事件來看待吧。

　　所以，如果有人對頭部以及載荷的內容解碼之后進行修改，再進行編碼的話，那么新的頭部和載荷的簽名和之前的簽名就將是不一樣的。而且，如果不知道服務器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。

　　服務器應用在接受到JWT后，會首先對頭部和載荷的內容用同一算法再次簽名。那么服務器應用是怎么知道我們用的是哪一種算法呢？別忘了，我們在JWT的頭部中已經用alg字段指明了我們的加密算法了。

　　如果服務器應用對頭部和載荷再次以同樣方法簽名之后發現，自己計算出來的簽名和接受到的簽名不一樣，那么就說明這個Token的內容被別人動過的，我們應該拒絕這個Token，返回一個HTTP 401 Unauthorized響應。

注意：在JWT中，不應該在載荷里面加入任何敏感的數據，比如用戶的密碼。

4、如何應用

一般是在請求頭里加入Authorization，並加上Bearer標注：

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

服務端會驗證token，如果驗證通過就會返回相應的資源。

5、安全相關

• 不應該在jwt的payload部分存放敏感信息，因為該部分是客戶端可解密的部分。
• 保護好secret私鑰，該私鑰非常重要。
• 如果可以，請使用https協議

6、對Token認證的五點認識

• 一個Token就是一些信息的集合；
• 在Token中包含足夠多的信息，以便在后續請求中減少查詢數據庫的幾率；
• 服務端需要對cookie和HTTP Authrorization Header進行Token信息的檢查；
• 基於上一點，你可以用一套token認證代碼來面對瀏覽器類客戶端和非瀏覽器類客戶端；
• 因為token是被簽名的，所以我們可以認為一個可以解碼認證通過的token是由我們系統發放的，其中帶的信息是合法有效的；

三、傳統的session認證

我們知道，http協議本身是一種無狀態的協議，而這就意味着如果用戶向我們的應用提供了用戶名和密碼來進行用戶認證，那么下一次請求時，用戶還要再一次進行用戶認證才行，因為根據http協議，我們並不能知道是哪個用戶發出的請求，所以為了讓我們的應用能識別是哪個用戶發出的請求，我們只能在服務器存儲一份用戶登錄的信息，這份登錄信息會在響應時傳遞給瀏覽器，告訴其保存為cookie,以便下次請求時發送給我們的應用，這樣我們的應用就能識別請求來自哪個用戶了,這就是傳統的基於session認證。

但是這種基於session的認證使應用本身很難得到擴展，隨着不同客戶端用戶的增加，獨立的服務器已無法承載更多的用戶，而這時候基於session認證應用的問題就會暴露出來。

基於session認證所顯露的問題

Session: 每個用戶經過我們的應用認證之后，我們的應用都要在服務端做一次記錄，以方便用戶下次請求的鑒別，通常而言session都是保存在內存中，而隨着認證用戶的增多，服務端的開銷會明顯增大。

擴展性: 用戶認證之后，服務端做認證記錄，如果認證的記錄被保存在內存中的話，這意味着用戶下次請求還必須要請求在這台服務器上,這樣才能拿到授權的資源，這樣在分布式的應用上，相應的限制了負載均衡器的能力。這也意味着限制了應用的擴展能力。

CSRF: 因為是基於cookie來進行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊。

基於token的鑒權機制

基於token的鑒權機制類似於http協議也是無狀態的，它不需要在服務端去保留用戶的認證信息或者會話信息。這就意味着基於token認證機制的應用不需要去考慮用戶在哪一台服務器登錄了，這就為應用的擴展提供了便利。

流程上是這樣的：

• 用戶使用用戶名密碼來請求服務器
• 服務器進行驗證用戶的信息
• 服務器通過驗證發送給用戶一個token
• 客戶端存儲token，並在每次請求時附送上這個token值
• 服務端驗證token值，並返回數據

這個token必須要在每次請求時傳遞給服務端，它應該保存在請求頭里， 另外，服務端要支持CORS(跨來源資源共享)策略，一般我們在服務端這么做就可以了 Access-Control-Allow-Origin:*。


四、token的優點

• 支持跨域訪問: Cookie是不允許垮域訪問的，這一點對Token機制是不存在的，前提是傳輸的用戶認證信息通過HTTP頭傳輸。
• 無狀態(也稱：服務端可擴展行):Token機制在服務端不需要存儲session信息，因為Token 自身包含了所有登錄用戶的信息，只需要在客戶端的cookie或本地介質存儲狀態信息。
• 更適用CDN: 可以通過內容分發網絡請求你服務端的所有資料（如：javascript，HTML,圖片等），而你的服務端只要提供API即可。
• 去耦: 不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，只要在你的API被調用的時候，你可以進行Token生成調用即可。
• 更適用於移動應用: 當你的客戶端是一個原生平台（iOS, Android，Windows 8等）時，Cookie是不被支持的（你需要通過Cookie容器進行處理），這時采用Token認證機制就會簡單得多。
• CSRF:因為不再依賴於Cookie，所以你就不需要考慮對CSRF（跨站請求偽造）的防范。
• 性能: 一次網絡往返時間（通過數據庫查詢session信息）總比做一次HMACSHA256計算 的Token驗證和解析要費時得多。
• 不需要為登錄頁面做特殊處理: 如果你使用Protractor 做功能測試的時候，不再需要為登錄頁面做特殊處理。
• 基於標准化:你的API可以采用標准化的 JSON Web Token (JWT). 這個標准已經存在多個后端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）。
• 因為json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。
• 因為有了payload部分，所以JWT可以在自身存儲一些其他業務邏輯所必要的非敏感信息。
• 便於傳輸，jwt的構成非常簡單，字節占用很小，所以它是非常便於傳輸的。
• 它不需要在服務端保存會話信息, 所以它易於應用的擴展。

五、JWT的JAVA實現

Java中對JWT的支持可以考慮使用JJWT開源庫；JJWT實現了JWT, JWS, JWE 和 JWA RFC規范；下面將簡單舉例說明其使用：

1、生成Token碼

import javax.crypto.spec.SecretKeySpec;
import javax.xml.bind.DatatypeConverter;
import java.security.Key;
import io.jsonwebtoken.*;
import java.util.Date;    
 
//Sample method to construct a JWT
 
private String createJWT(String id, String issuer, String subject, long ttlMillis) {
 
//The JWT signature algorithm we will be using to sign the token
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
 
long nowMillis = System.currentTimeMillis();
Date now = new Date(nowMillis);
 
//We will sign our JWT with our ApiKey secret
byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(apiKey.getSecret());
Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
 
  //Let's set the JWT Claims
JwtBuilder builder = Jwts.builder().setId(id)
                                .setIssuedAt(now)
                                .setSubject(subject)
                                .setIssuer(issuer)
                                .signWith(signatureAlgorithm, signingKey);
 
//if it has been specified, let's add the expiration
if (ttlMillis >= 0) {
    long expMillis = nowMillis + ttlMillis;
    Date exp = new Date(expMillis);
    builder.setExpiration(exp);
}
 
//Builds the JWT and serializes it to a compact, URL-safe string
return builder.compact();
}

2、解碼和驗證Token碼

import javax.xml.bind.DatatypeConverter;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.Claims;
 
//Sample method to validate and read the JWT
private void parseJWT(String jwt) {
//This line will throw an exception if it is not a signed JWS (as expected)
Claims claims = Jwts.parser()        
   .setSigningKey(DatatypeConverter.parseBase64Binary(apiKey.getSecret()))
   .parseClaimsJws(jwt).getBody();
System.out.println("ID: " + claims.getId());
System.out.println("Subject: " + claims.getSubject());
System.out.println("Issuer: " + claims.getIssuer());
System.out.println("Expiration: " + claims.getExpiration());
}

文章整理自：

https://blog.csdn.net/buyaoshuohua1/article/details/73739419

https://www.cnblogs.com/xiekeli/p/5607107.html#top

https://blog.csdn.net/SoftwareOscar/article/details/78538346

https://blog.csdn.net/Jack__Frost/article/details/64964208

http://blog.leapoahead.com/2015/09/06/understanding-jwt/