基於jwt的token驗證

https://www.cnblogs.com/java-jun-world2099/p/9146143.html

一、什麼是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、如何應用

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

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

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

4、安全相關 

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

5、對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/