者：古時的風箏

原文鏈接：https://www.cnblogs.com/fengzheng/p/13527425.html

JWT 全稱是 JSON Web Token，是目前非常流行的跨域認證解決方案，在單點登錄場景中經常使用到。

有些人覺得它非常好用，用了它之后就不用在服務端借助 redis 實現認證過程了，但是，還有一部分人認為它生來就有缺陷，根本不能用。

這是為什么呢？

傳統的認證方式

從一個登錄場景說起

你平時用過那么多網站和 APP，其中有很多都是需要登錄的吧，那咱們就選一個場景出來說說。

以一個電商系統為例，如果你想要下單，首先需要注冊一個賬號，擁有了賬號之后，需要輸入用戶名（比如手機號或郵箱）、密碼完成登錄過程。之后你在一段時間內再次進入系統，是不需要輸入用戶名和密碼的，只有在連續長時間不登錄的情況下（例如一個月沒登錄過）訪問系統，才需要再次輸入用戶名和密碼。

對于那些使用頻率很高的網站或應用，通常是很長時間都不需要輸入密碼的，以至于你在換了一臺電腦或者一部手機之后，一些經常使用的網站或 APP 的密碼都不記得了。

早期的 Cookie-Session 認證方式

早期互聯網以 web 為主，客戶端是瀏覽器 ，所以 Cookie-Session 方式是早期最常用的認證方式，直到現在，一些 web 網站依然用這種方式做認證。

認證過程大致如下：

1. 用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統；
2. 服務端驗證后，創建一個 Session 信息，并且將 SessionID 存到 cookie，發送回瀏覽器；
3. 下次客戶端再發起請求，自動帶上 cookie 信息，服務端通過 cookie 獲取 Session 信息進行校驗；

但是為什么說它是傳統的認證方式，因為現在人手一部智能手機，很多人都不用電腦，平時都是使用手機上的各種 APP，比如淘寶、拼多多等。
在這種潮流之下，傳統的 Cookie-Session 就遇到了一些問題：
1、首先，Cookie-Session 只能在 web 場景下使用，如果是 APP 呢，APP 可沒有地方存 cookie。
現在的產品基本上都同時提供 web 端和 APP 兩種使用方式，有點產品甚至只有 APP。

2、退一萬步說，你做的產品只支持 web，也要考慮跨域問題， 但Cookie 是不能跨域的。
拿天貓商城來說，當你進入天貓商城后，會看到頂部有天貓超市、天貓國際、天貓會員這些菜單。而點擊這些菜單都會進入不同的域名，不同的域名下的 cookie 都是不一樣的，你在 A 域名下是沒辦法拿到 B 域名的 cookie 的，即使是子域也不行。

3、如果是分布式服務，需要考慮 Session 同步問題。
現在的互聯網網站和 APP 基本上都是分布式部署，也就是服務端不止一臺機器。當某個用戶在頁面上進行登錄操作后，這個登錄動作必定是請求到了其中某一臺服務器上。你的身份信息得保存下來吧，傳統方式就是存 Session。

接下來，問題來了。你訪問了幾個頁面，這時，有個請求經過負載均衡，路由到了另外一臺服務器（不是你登錄的那臺）。當后臺接到請求后，要檢查用戶身份信息和權限，于是接口開始從從 Session 中獲取用戶信息。但是，這臺服務器不是當時登錄的那臺，并沒存你的 Session ，這樣后臺服務就認為你是一個非登錄的用戶，也就不能給你返回數據了。

所以，為了避免這種情況的發生，就要做 Session 同步。一臺服務器接收到登錄請求后，在當前服務器保存 Session 后，也要向其他幾個服務器同步。

4、cookie 存在 CSRF（跨站請求偽造）的風險。 跨站請求偽造，是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。CSRF 利用的是網站對用戶網頁瀏覽器的信任。簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并運行一些操作（比如購買商品）。由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶發起的操作。
比如說我是一個黑客，我發現你經常訪問的一個技術網站存在 CSRF 漏洞。發布文章支持 html 格式，進而我在 html 中加入一些危險內容，例如

 <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

假設 src 指向的地址是一個你平時用的購物網站的付款地址（當然只是舉例，真正的攻擊可沒這么簡單），如果你之前登錄過并且標識你身份信息的 cookie 已經保存下來了。當你刷到我發布的這篇文章的時候，img 標簽一加載，這個 CSRF 攻擊就會起作用，在你不知情的情況下向這個網站付款了。

Cookie-Session 改造版

由于傳統的 Cookie-Session 認證存在諸多問題，那可以把上面的方案改造一下。
1、改造 Cookie 既然 Cookie 不能在 APP 等非瀏覽器中使用，那就不用 cookie 做客戶端存儲，改用其他方式。
改成什么呢？
web 中可以使用 local storage，APP 中使用客戶端數據庫，這樣既能這樣就實現了跨域，并且避免了 CSRF 。

2、服務端也不存 Session 了，把 Session 信息拿出來存到 Redis 等內存數據庫中，這樣即提高了速度，又避免了 Session 同步問題；

經過改造之后變成了如下的認證過程：

1. 用戶輸入用戶名、密碼或者用短信驗證碼方式登錄系統；
2. 服務端經過驗證，將認證信息構造好的數據結構存儲到 Redis 中，并將 key 值返回給客戶端；
3. 客戶端拿到返回的 key，存儲到 local storage 或本地數據庫；
4. 下次客戶端再次請求，把 key 值附加到 header 或者 請求體中；
5. 服務端根據獲取的 key，到 Redis 中獲取認證信息；

下面兩張圖分別演示了首次登錄和非首次登錄的過程。

經過一頓猛如虎的改造，解決了傳統 Cookie-Session 方式存在的問題。這種改造需要開發者在項目中自行完成。改造起來肯定是費時費力的，而且還有可能存在漏洞。

JWT 出場

這時，JWT 就可以上場了，JWT 就是一種Cookie-Session改造版的具體實現，讓你省去自己造輪子的時間，JWT 還有個好處，那就是你可以不用在服務端存儲認證信息（比如 token），完全由客戶端提供，服務端只要根據 JWT 自身提供的解密算法就可以驗證用戶合法性，而且這個過程是安全的。

如果你是剛接觸 JWT，最有疑問的一點可能就是： JWT 為什么可以完全依靠客戶端(比如瀏覽器端)就能實現認證功能，認證信息全都存在客戶端，怎么保證安全性？

JWT 數據結構

JWT 最后的形式就是個字符串，它由頭部、載荷與簽名這三部分組成，中間以「.」分隔。像下面這樣：

頭部

頭部以 JSON 格式表示，用于指明令牌類型和加密算法。形式如下，表示使用 JWT 格式，加密算法采用 HS256，這是最常用的算法，除此之外還有很多其他的。

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

對應上圖的紅色 header 部分，需要 Base64 編碼。

載荷

用來存儲服務器需要的數據，比如用戶信息，例如姓名、性別、年齡等，要注意的是重要的機密信息最好不要放到這里，比如密碼等。

{
  "name": "古時的風箏",
  "introduce": "英俊瀟灑"
}

另外，JWT 還規定了 7 個字段供開發者選用。

• iss (issuer)：簽發人
• exp (expiration time)：過期時間
• sub (subject)：主題
• aud (audience)：受眾
• nbf (Not Before)：生效時間
• iat (Issued At)：簽發時間
• jti (JWT ID)：編號

這部分信息也是要用 Base64 編碼的。

簽名

簽名有一個計算公式。

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

使用HMACSHA256算法計算得出，這個方法有兩個參數，前一個參數是 （base64 編碼的頭部 + base64 編碼的載荷）用點號相連，后一個參數是自定義的字符串密鑰，密鑰不要暴露在客戶端，而應該服務器知道。

使用方式

了解了 JWT 的結構和算法后，那怎么使用呢？假設我這兒有個網站。

1、在用戶登錄網站的時候，需要輸入用戶名、密碼或者短信驗證的方式登錄，登錄請求到達服務端的時候，服務端對賬號、密碼進行驗證，然后計算出 JWT 字符串，返回給客戶端。

2、客戶端拿到這個 JWT 字符串后，存儲到 cookie 或者 瀏覽器的 LocalStorage 中。

3、再次發送請求，比如請求用戶設置頁面的時候，在 HTTP 請求頭中加入 JWT 字符串，或者直接放到請求主體中。

4、服務端拿到這串 JWT 字符串后，使用 base64的頭部和 base64 的載荷部分，通過HMACSHA256算法計算簽名部分，比較計算結果和傳來的簽名部分是否一致，如果一致，說明此次請求沒有問題，如果不一致，說明請求過期或者是非法請求。

怎么保證安全性的

保證安全性的關鍵就是 HMACSHA256 或者與它同類型的加密算法，因為加密過程是不可逆的，所以不能根據傳到前端的 JWT 傳反解到密鑰信息。

另外，不同的頭部和載荷加密之后得到的簽名都是不同的，所以，如果有人改了載荷部分的信息，那最后加密出的結果肯定就和改之前的不一樣的，所以，最后驗證的結果就是不合法的請求。

別人拿到完整 JWT 還安全嗎

假設載荷部分存儲了權限級別相關的字段，強盜拿到 JWT 串后想要修改為更高權限的級別，上面剛說了，這種情況下是肯定不會得逞的，因為加密出來的簽名會不一樣，服務器可能很容易的判別出來。

那如果強盜拿到后不做更改，直接用呢，那就沒有辦法了，為了更大程度上防止被強盜盜取，應該使用 HTTPS 協議而不是 HTTP 協議，這樣可以有效的防止一些中間劫持攻擊行為。

有同學就要說了，這一點也不安全啊，拿到 JWT 串就可以輕松模擬請求了。確實是這樣，但是前提是你怎么樣能拿到，除了上面說的中間劫持外，還有什么辦法嗎？

除非強盜直接拿了你的電腦，那這樣的話，對不起，不光 JWT 不安全了，其他任何網站，任何認證方式都不安全。

雖然這樣的情況很少，但是在使用 JWT 的時候仍然要注意合理的設置過期時間，不要太長。

一個問題

JWT 有個問題，導致很多開發團隊放棄使用它，那就是一旦頒發一個 JWT 令牌，服務端就沒辦法廢棄掉它，除非等到它自身過期。有很多應用默認只允許最新登錄的一個客戶端正常使用，不允許多端登錄，JWT 就沒辦法做到，因為頒發了新令牌，但是老的令牌在過期前仍然可用。這種情況下，就需要服務端增加相應的邏輯。

常用的 JWT 庫

JWT 官網列出了各種語言對應的庫，其中 Java 的如下幾個。

以 java-jwt為例。

1、引入對應的 Maven 包。

<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>3.10.3</version>
</dependency>

2、在登錄時，調用 create 方法得到一個令牌，并返回給前端。

public static String create(){
  try {
    Algorithm algorithm = Algorithm.HMAC256("secret");
    String token = JWT.create()
      .withIssuer("auth0")
      .withSubject("subject")
      .withClaim("name","古時的風箏")
      .withClaim("introduce","英俊瀟灑")
      .sign(algorithm);
    System.out.println(token);
    return token;
  } catch (JWTCreationException exception){
    //Invalid Signing configuration / Couldn't convert Claims.
    throw exception;
  }
}

3、登錄成功后，再次發起請求的時候將 token 放到 header 或者請求體中，服務端對 token 進行驗證。

public static Boolean verify(String token){
  try {
    Algorithm algorithm = Algorithm.HMAC256("secret");
    JWTVerifier verifier = JWT.require(algorithm)
      .withIssuer("auth0")
      .build(); //Reusable verifier instance
    DecodedJWT jwt = verifier.verify(token);
    String payload = jwt.getPayload();
    String name = jwt.getClaim("name").asString();
    String introduce = jwt.getClaim("introduce").asString();
    System.out.println(payload);
    System.out.println(name);
    System.out.println(introduce);
    return true;
  } catch (JWTVerificationException exception){
    //Invalid signature/claims
    return false;
  }
}

4、用 create 方法生成 token，并用 verify 方法驗證一下。

public static void main(String[] args){
  String token = create();
  Boolean result = verify(token);
  System.out.println(result);
}

得到下面的結果

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0.ooQ1K_XyljjHf34Nv5iJvg1MQgVe6jlphxv4eeFt8pA
eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0
古時的風箏
英俊瀟灑
true

使用 create 方法創建的 JWT 串可以通過驗證。

而如果我將 JWT 串中的載荷部分，兩個點號中間的部分修改一下，然后再調用 verify 方法驗證，會出現 JWTVerificationException異常，不能通過驗證。

ession簡介#

做過Web開發的程序員應該對Session都比較熟悉，Session是一塊保存在服務器端的內存空間，一般用于保存用戶的會話信息。

用戶通過用戶名和密碼登陸成功之后，服務器端程序會在服務器端開辟一塊Session內存空間并將用戶的信息存入這塊空間，同時服務器會
在cookie中寫入一個Session_id的值，這個值用于標識這個內存空間。

下次用戶再來訪問的話會帶著這個cookie中的session_id，服務器拿著這個id去尋找對應的session，如果session中已經有了這個用戶的
登陸信息，則說明用戶已經登陸過了。

使用Session保持會話信息使用起來非常簡單，技術也非常成熟。但是也存在下面的幾個問題：

• 服務器壓力大：通常Session是存儲在內存中的，每個用戶通過認證之后都會將session數據保存在服務器的內存中，而當用戶量增大時，服務器的壓力增大。
• Session共享：現在很多應用都是分布式集群，需要我們做額外的操作進行Session共享；
• CSRF跨站偽造請求攻擊：Session機制是基于瀏覽器端的cookie的，cookie如果被截獲，用戶就會很容易受到跨站請求偽造的攻擊。

基于token的認證#

基于token的認證機制將認證信息返回給客戶端并存儲。下次訪問其他頁面，需要從客戶端傳遞認證信息回服務端。簡單的流程如下：

• 客戶端使用用戶名跟密碼請求登錄；
• 服務端收到請求，去驗證用戶名與密碼；
• 驗證成功后，服務端會簽發一個 Token，再把這個 Token 發送給客戶端；
• 客戶端收到 Token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里；
• 客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 Token；
• 服務端收到請求，然后去驗證客戶端請求里面帶著的 Token，如果驗證成功，就向客戶端返回請求的數據；

基于token的驗證機制，有以下的優點：

• 支持跨域訪問，將token置于請求頭中，而cookie是不支持跨域訪問的；
• 無狀態化，服務端無需存儲token，只需要驗證token信息是否正確即可，而session需要在服務端存儲，一般是通過cookie中的sessionID在服務端查找對應的session；
• 無需綁定到一個特殊的身份驗證方案（傳統的用戶名密碼登陸），只需要生成的token是符合我們預期設定的即可；
• 更適用于移動端（Android，iOS，小程序等等），像這種原生平臺不支持cookie，比如說微信小程序，每一次請求都是一次會話，當然我們可以每次去手動為他添加cookie，詳情請查看博主另一篇博客；
• 避免CSRF跨站偽造攻擊，還是因為不依賴cookie；

缺點的話一個就是相比較于傳統的session登陸機制實現起來略微復雜一點，另外一個比較大的缺點是由于服務器不保存 token，因此無法在使用過程中廢止某個 token，或者更改 token 的權限。也就是說，一旦 token 簽發了，在到期之前就會始終有效，除非服務器部署額外的邏輯。

退出登陸的話，只要前端清除token信息即可。

基于JWT的token認證實現#

JWT（JSON Web Token）就是基于token認證的代表，這邊就用JWT為列來介紹基于token的認證機制。

需要引入JWT的依賴

<dependency>
  <groupId>com.auth0</groupId>
  <artifactId>java-jwt</artifactId>
  <version>3.8.2</version>
</dependency>

生成token和驗證token的工具類如下：

public class JWTTokenUtil {
    //設置過期時間
    private static final long EXPIRE_DATE=30*60*100000;
    //token秘鑰
    private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";

    public static String token (String username,String password){

        String token = "";
        try {
            //過期時間
            Date date = new Date(System.currentTimeMillis()+EXPIRE_DATE);
            //秘鑰及加密算法
            Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
            //設置頭部信息
            Map<String,Object> header = new HashMap<>();
            header.put("typ","JWT");
            header.put("alg","HS256");
            //攜帶username，password信息，生成簽名
            token = JWT.create()
                    .withHeader(header)
                    .withClaim("username",username)
                    .withClaim("password",password).withExpiresAt(date)
                    .sign(algorithm);
        }catch (Exception e){
            e.printStackTrace();
            return  null;
        }
        return token;
    }

    public static boolean verify(String token){
        /**
         * @desc   驗證token，通過返回true
         * @params [token]需要校驗的串
         **/
        try {
            Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
            JWTVerifier verifier = JWT.require(algorithm).build();
            DecodedJWT jwt = verifier.verify(token);
            return true;
        }catch (Exception e){
            e.printStackTrace();
            return  false;
        }
    }
    public static void main(String[] args) {
        String username ="name1";
        String password = "pw1";
        //注意，一般不會把密碼等私密信息放在payload中，這邊只是舉個列子
        String token = token(username,password);
        System.out.println(token);
        boolean b = verify(token);
        System.out.println(b);
    }
}

執行結果如下：

Connected to the target VM, address: '127.0.0.1:11838', transport: 'socket'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXNzd29yZCI6IjEyMyIsImV4cCI6MTU5NzM5Nzc0OCwidXNlcm5hbWUiOiJ6aGFuZ3NhbiJ9.LI5S_nX-YcqtExI9UtKiP8FPqpQW_ccaws2coLzyOS0
true

關于DecodedJWT這個類，大家可以重點看下，里面包含了解碼后的用戶信息。

JWT的使用說明#

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

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

Authorization: Bearer <token>

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

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

為了減少盜用，JWT 不應該使用 HTTP 協議明碼傳輸，要使用 HTTPS 協議傳輸。（或者是對JWT在前后端之間進行加密之后在傳輸）

關于JWT的一個問題#

上面生成JWT token的過程關鍵點就是密鑰，假如這個密鑰泄露了，那是不是就可以偽造token了。

還有就是生產環境的密鑰值，開發的程序員大概率是知道的，怎么防止程序要監守自盜，偽造token值呢？希望有經驗的大佬指教下。

//token秘鑰
private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";

關于上面的問題，@仙湖碼農 給出了一個簡單易懂的方案~

jwt 來生成token，還有一個玩法，用戶登錄時，生成token的 SecretKey 是一個隨機數，也就是說每個用戶，每次登錄時jwt SecretKey 是隨機數，并保存到緩存，key是登錄賬戶，（當然了，分布式緩存的話，就用Redis，sqlserver緩存等等），總之，客戶端訪問接口是，header 要帶登錄賬戶，和token，服務端拿到登錄賬號，到緩存去撈相應的SecretKey ，然后再進行token校驗。可以防偽造token了（這個方案在一定程度上能防止偽造，但是不能防止token泄露被劫持）。

獲取refresh token的方法#

• https://www.cnblogs.com/wyt007/p/11459547.html

常生活中，訪問https網頁時會提示“與此網站是安全鏈接”，網站部署了SSL證書也會有證書頒發機構信息，瀏覽器根證書受信，加密安全等等提示，表示訪問的網頁是受到數據加密，安全性網站。瀏覽器驗證SSL或TLS證書的過程是為了確保與網站之間的通信是安全的。SSL/TLS證書用于加密數據傳輸，防止中間人攻擊，并驗證網站的身份。那么瀏覽器是如何對SSL證書進行驗證呢？

1、獲取證書：

當用戶嘗試訪問一個使用HTTPS的網站時，瀏覽器首先會向服務器發送一個連接請求。服務器響應這個請求并提供其SSL/TLS證書。如未部署SSL證書，通常會提示“您與該網站的連接不是私密連接，存在安全隱患。”

2、檢查證書鏈：

SSL證書通常由一個證書頒發機構（CA）簽名。證書中包含了公鑰、域名和頒發者的信息。瀏覽器會檢查證書的簽名是否來自一個受信任的CA，以及該證書是否適用于所請求的網站。

以國產SSL證書品牌JoySSL申請為例，打開JoySSL官網，選擇需要的證書類型（單域名、多域名、通配符、IP證書、代碼簽名證書等等），在驗簽后，按步驟提示完成在服務器中的部署就可以了。

打開JoySSL官網，填寫注冊碼230921，即可免費獲得SSL證書。

https://www.joyssl.com/certificate/select/free.html?nid=21

3、驗證簽名：

瀏覽器使用CA的公鑰來驗證證書的數字簽名。如果簽名有效，這意味著證書沒有被篡改過，且確實是由CA簽發的。

4、檢查有效期：

SSL證書有有效期，過期的證書將被視為無效。瀏覽器會檢查證書的有效開始日期和結束日期，確保當前日期在有效期內。如證書未部署上或者證書有效期時間已過，也會有證書過期或者非安全鏈接等等提示。

5、檢查域名匹配：

證書中包含的域名必須與用戶正在訪問的網站域名相匹配。例如，如果你訪問的是www.baidu.com，那么證書中的域名也應該是www.baidu.com或baidu.com。

6、檢查黑名單：

瀏覽器會檢查證書是否在任何已知的黑名單中，以避免使用已被撤銷的證書。

7、建立安全連接：

如果上述所有檢查都通過，瀏覽器和服務器之間將進行密鑰交換，以創建一個安全的、加密的數據通道。這通常涉及選擇加密算法、生成會話密鑰等步驟。常用的是國際算法，能適用目前市場上主流瀏覽器，也有部分教務、政務機構有特殊要求。

8、警告和錯誤：

如果在驗證過程中發現任何問題，比如證書無效、域名不匹配或已過期，瀏覽器將顯示警告信息或阻止用戶訪問該網站，以保護用戶的隱私和數據安全。