摘要：在使用非對稱加密算法進行簽名的時候，還可以用于驗證的發(fā)件人是否與中申明的發(fā)件人是同一個人。如果沒有用非對稱加密算法的話，把復(fù)制之后直接可以去官網(wǎng)在線解析。

這篇博客主要是簡單介紹了一下什么是JWT，以及如何在Spring Boot項目中使用JWT(JSON Web Token)。

老生常談的開頭，我們要用這樣一種工具，首先得知道以下幾個問題。

這個工具是什么，這個工具解決了什么問題

是否適用于當前我們所處得業(yè)務(wù)場景

用了之后是否會帶來任何其他問題

怎么用才是最佳實踐

那什么是JWT呢？以下是我對jwt官網(wǎng)上對JWT介紹的翻譯。

JSON Web Token （JWT）是一種定義了一種緊湊并且獨立的，用于在各方之間使用JSON對象安全的傳輸信息的一個開放標準（RFC 7519）。

現(xiàn)在我們知道，JWT其實是一種開放標準，用于在多點之間安全地傳輸用JSON表示的數(shù)據(jù)。在傳輸?shù)倪^程中，JWT以字符串的形式出現(xiàn)在我們的視野中。該字符串中的信息可以通過數(shù)字簽名進行驗證和信任。

JWT在實際的開發(fā)中，有哪些應(yīng)用場景呢？

這應(yīng)該算是JWT最常見的使用場景。在前端界面中，一旦用戶登錄成功，會接收到后端返回的JWT。后續(xù)的請求都會包含后端返回的JWT，作為對后端路由、服務(wù)以及資源的訪問的憑證。

利用JWT在多方之間相互傳遞信息具有一定的安全性，例如JWT可以用HMAC、RSA非對稱加密算法以及ECDSA數(shù)字簽名算法對JWT進行簽名，可以確保消息的發(fā)送者是真的發(fā)送者，而且使用header和payload進行的簽名計算，我們還可以驗證發(fā)送的消息是否被篡改了。

通俗來講JWT由header.payload.signature三部分組成的字符串，網(wǎng)上有太多帖子介紹這一塊了，所以在這里就簡單介紹一下就好了。

header由使用的簽名算法和令牌的類型的組成，例如令牌的類型就是JWT這種開放標準，而使用的簽名算法就是HS256，也就是HmacSHA256算法。其他的加密算法還有HmacSHA512、SHA512withECDSA等等。

然后將這個包含兩個屬性的JSON對象轉(zhuǎn)化為字符串然后使用Base64編碼，最終形成了JWT的header。

payload說直白一些就類似你的requestBody中的數(shù)據(jù)。只不過是分了三種類型，預(yù)先申明好的、自定義的以及私有的。像iss發(fā)件人，exp過期時間都是預(yù)先注冊好的申明。

預(yù)先申明在載荷中的數(shù)據(jù)不是強制性的使用，但是官方建議使用。然后這串類似于requestBody的JSON經(jīng)過Base64編碼形成了JWT的第二部分。

如果要生成signature，就需要使用jwt自定義配置項中的secret，也就是Hmac算法加密所需要的密鑰。將之前經(jīng)過Base64編碼的header和payload用.相連，再使用自定義的密鑰，對該消息進行簽名，最終生成了簽名。

生成的簽名用于驗證消息在傳輸?shù)倪^程中沒有被更改。在使用非對稱加密算法進行簽名的時候，還可以用于驗證JWT的發(fā)件人是否與payload中申明的發(fā)件人是同一個人。

代碼如下。

public String createJwt(String userId, String projectId) throws IllegalArgumentException, UnsupportedEncodingException {
    Algorithm al = Algorithm.HMAC256(secret);
    Instant instant = LocalDateTime.now().plusHours(outHours).atZone(ZoneId.systemDefault()).toInstant();
    Date expire = Date.from(instant);
    String token = JWT.create()
            .withIssuer(issuer)
            .withSubject("userInfo")
            .withClaim("user_id", userId)
            .withClaim("project_id", projectId)
            .withExpiresAt(expire)
            .sign(al);
    return token;
}

傳入的兩個Claim是項目里自定義的payload，al是選擇的算法，而secret就是對信息簽名的密鑰，subject則是該token的主題，withExpiresAt標識了該token的過期時間。

在用戶登錄系統(tǒng)成功之后，將token作為返回參數(shù)，返回給前端。

在token返回給前端之后，后端要做的就是驗證這個token是否是合法的，是否可以訪問服務(wù)器的資源。主要可以通過以下幾種方式去驗證。

使用JWTVerifier解析token，這是驗證token是否合法的第一步，例如前端傳過來的token是一串沒有任何意義的字符串，在這一步就可以拋出錯誤。示例代碼如下。

try {
    Algorithm algorithm = Algorithm.HMAC256(secret);
    JWTVerifier verifier = JWT.require(algorithm).build();
    DecodedJWT jwt = verifier.verify(token);
} catch (JWTVerificationException e) {
    e.printStackTrace();
}

JWTVerifier可以使用用制定secret簽名的算法，指定的claim來驗證token的合法性。

判斷了token是有效的之后，再對token的時效性進行驗證。

try {
    Algorithm algorithm = Algorithm.HMAC256(secret);
    JWTVerifier verifier = JWT.require(algorithm).build();
    DecodedJWT jwt = verifier.verify(token);
    if (jwt.getExpiresAt().before(new Date())) {
        System.out.println("token已過期");
        return null;
    }
} catch (JWTVerificationException e) {
    e.printStackTrace();
    return null;
}

如果該token過期了，則不允許訪問服務(wù)器資源。具體的流程如下。

上面創(chuàng)建token的有效時間是可以配置的，假設(shè)是2個小時，并且用戶登錄進來連續(xù)工作了1小時59分鐘，在進行一個很重要的操作的時候，點擊確定，這個時候token過期了。如果程序沒有保護策略，那么用戶接近兩個小時的工作就成為了無用功。

遇到這樣的問題，我們之前的流程設(shè)計必然面對一次重構(gòu)。可能大家會有疑問，不就是在用戶登錄之后，每次操作對去刷新一次token的過期時間嗎？

那么問題來了，我們知道token是由header.payload.signature三段內(nèi)容組成的，而過期時間則是屬于payload，如果改變了過期的時間，那么最終生成的payload的hash則勢必與上一次生成的不同。

換句話說，這是一個全新的token。前端要怎么接收這個全新的token呢？可想到的解決方案無非就是每次請求，根據(jù)response header中的返回不斷的刷新的token。但是這樣的方式侵入了前端開發(fā)的業(yè)務(wù)層。使其每一個接口都需要去刷新token。

大家可能會說，無非就是加一個攔截器嘛，對業(yè)務(wù)侵入不大啊。即使這部分邏輯是寫在攔截器里的，但是前端因為token鑒權(quán)的邏輯而多出了這部分代碼。而這部分代碼從職能分工上來說，其實是后端的邏輯。

說的直白一些，刷新token，對token的時效性進行管理，應(yīng)該是由后端來做。前端不需要也不應(yīng)該去關(guān)心這一部分的邏輯。

綜上所述，刷新token的過期時間勢必要放到后端，并且不能通過判斷JWT中payload中的expire來判斷token是否有效。

所以，在用戶登錄成功之后并將token返回給前端的同時，需要以某一個唯一表示為key，當前的token為value，寫入Redis緩存中。并且在每次用戶請求成功后，刷新token的過期時間，流程如下所示。

經(jīng)過這樣的重構(gòu)之后，流程就變成了這樣。

在流程中多了一個刷新token的流程。只要用戶登錄了系統(tǒng)，每一次的操作都會刷新token的過期時間，就不會出現(xiàn)之前說的在進行某個操作時突然失效所造成數(shù)據(jù)丟失的情況。

在用戶登錄之后的兩個小時內(nèi)，如果用戶沒有進行任何操作，那么2小時后再次請求接口就會直接被服務(wù)器拒絕訪問。

總的來說，JWT中是不建議放特別敏感信息的。如果沒有用非對稱加密算法的話，把token復(fù)制之后直接可以去jwt官網(wǎng)在線解析。如果請求被攔截到了，里面的所有信息等于是透明的。

但是JWT可以用來當作一段時間內(nèi)運行訪問服務(wù)器資源的憑證。例如JWT的payload中帶有userId這個字段，那么就可以對該token標識的用戶的合法性進行驗證。例如，該用戶當前狀態(tài)是否被鎖定？該userId所標識的用戶是否存在于我們的系統(tǒng)？等等。

并且通過實現(xiàn)token的公用，可以實現(xiàn)用戶的多端同時登錄。像之前的登錄之后創(chuàng)建token，就限定了用戶只能同時在一臺設(shè)備上登錄。

歡迎大家瀏覽之前的文章：個人博客，如果有說的不對的地方，還請不吝賜教。

JWT官網(wǎng)