jjwt
0.12.6
JJWT 旨在成為最易於使用和理解的程式庫，用於在 JVM 和 Android 上建立和驗證 JSON Web 令牌 (JWT) 和 JSON Web 金鑰 (JWK)。
JJWT 是完全基於 JOSE 工作小組 RFC 規範的純 Java 實作：
RFC 7519：JSON Web 令牌 (JWT)
RFC 7515：JSON Web 簽章 (JWS)
RFC 7516：JSON Web 加密 (JWE)
RFC 7517：JSON Web 金鑰 (JWK)
RFC 7518：JSON Web 演算法 (JWA)
RFC 7638：JSON Web 金鑰指紋
RFC 9278：JSON Web 金鑰指紋 URI
RFC 7797：JWS 未編碼有效負載選項
RFC 8037：Edwards 曲線演算法與 JWK
它由 Les Hazlewood 創建，並由貢獻者社群支持和維護。
JJWT 是根據 Apache 2.0 授權條款開源的。
PublicKeytoString()安全性在所有 Java 7+ JDK 和 Android 上功能齊全
自動安全最佳實務和斷言
易於學習和閱讀的 API
方便易讀的流暢介面，非常適合IDE自動補全快速編寫程式碼
所有實現的功能完全符合 RFC 規範，並根據 RFC 指定的測試向量進行測試
穩定實現，經過近 1,700 次測試，測試程式碼覆蓋率達到 100%。整個程式碼庫中的每個方法、語句和條件分支變體都經過測試，並且需要在每個建置中傳遞。
使用所有標準 JWS 演算法建立、解析和驗證數位簽章的緊湊型 JWT（又稱 JWS）：
| 識別符 | 簽名演算法 |
|---|---|
| 使用 SHA-256 的 HMAC |
| 使用 SHA-384 的 HMAC |
| 使用 SHA-512 的 HMAC |
| 使用 P-256 和 SHA-256 的 ECDSA |
| 使用 P-384 和 SHA-384 的 ECDSA |
| 使用 P-521 和 SHA-512 的 ECDSA |
| 使用 SHA-256 的 RSASSA-PKCS-v1_5 |
| 使用 SHA-384 的 RSASSA-PKCS-v1_5 |
| 使用 SHA-512 的 RSASSA-PKCS-v1_5 |
| 使用 SHA-256 的 RSASSA-PSS 和使用 SHA-256 1的 MGF1 |
| 使用 SHA-384 的 RSASSA-PSS 和使用 SHA-384 1的 MGF1 |
| 使用 SHA-512 的 RSASSA-PSS 和使用 SHA-512 1的 MGF1 |
| 愛德華茲曲線數位簽章演算法2 |
1.在執行時間類別路徑中需要 Java 11 或相容的 JCA 提供者（如 BouncyCastle）。
2 .執行時間類別路徑中需要 Java 15 或相容的 JCA 提供者（如 BouncyCastle）。
使用所有標準 JWE 加密演算法建立、解析和解密加密的緊湊型 JWT（又稱 JWE）：
| 識別符 | 加密演算法 |
|---|---|
| AES_128_CBC_HMAC_SHA_256認證加密演算法 |
| AES_192_CBC_HMAC_SHA_384認證加密演算法 |
| AES_256_CBC_HMAC_SHA_512認證加密演算法 |
| 使用 128 位元密鑰1 的AES GCM |
| 使用 192 位元密鑰1 的AES GCM |
| 使用 256 位元密鑰1 的AES GCM |
1 .執行時間類別路徑中需要 Java 8 或相容的 JCA 提供者（如 BouncyCastle）。
取得JWE加密和解密金鑰的所有金鑰管理演算法：
| 識別符 | 密鑰管理演算法 |
|---|---|
| RSAES-PKCS1-v1_5 |
| 使用預設參數的 RSAES OAEP |
| 使用 SHA-256 的 RSAES OAEP 和使用 SHA-256 的 MGF1 |
| 使用 128 位元金鑰的預設初始值的 AES 金鑰包裝 |
| 使用 192 位元金鑰的預設初始值的 AES 金鑰包裝 |
| 使用 256 位元金鑰的預設初始值的 AES 金鑰包裝 |
| 直接使用共享對稱金鑰作為CEK |
| 使用 Concat KDF 的橢圓曲線 Diffie-Hellman 臨時靜態金鑰協商 |
| ECDH-ES 使用 Concat KDF 和 CEK 包裹“A128KW” |
| ECDH-ES 使用 Concat KDF 和 CEK 包裹“A192KW” |
| ECDH-ES 使用 Concat KDF 和 CEK 包裹“A256KW” |
| 使用 128 位元金鑰1透過 AES GCM 進行金鑰包裝 |
| 使用 192 位元金鑰1透過 AES GCM 進行金鑰包裝 |
| 使用 256 位元金鑰1透過 AES GCM 進行金鑰包裝 |
| 具有 HMAC SHA-256 和“A128KW”包裝1 的PBES2 |
| 具有 HMAC SHA-384 和“A192KW”包裝1 的PBES2 |
| 具有 HMAC SHA-512 和“A256KW”包裝1 的PBES2 |
1 .執行時間類別路徑中需要 Java 8 或相容的 JCA 提供者（如 BouncyCastle）。
使用本機 Java Key類型以所有標準 JWA 金鑰格式建立、解析和驗證 JSON Web 金鑰 (JWK)：
| JWK 金鑰格式 | Java Key類型 | JJWT Jwk型 |
|---|---|---|
對稱金鑰 |
| |
橢圓曲線公鑰 |
| |
橢圓曲線私鑰 |
| |
RSA 公鑰 |
| |
RSA 私鑰 |
| |
XDH 私鑰 |
| |
XDH 私鑰 |
| |
EdDSA 公鑰 |
| |
EdDSA 私鑰 |
| |
1 .執行時間類別路徑中需要 Java 15 或相容的 JCA 提供者（如 BouncyCastle）。
2 .執行時間類別路徑中需要 Java 15 或相容的 JCA 提供者（如 BouncyCastle）。
超出規範的便利增強功能，例如
適用於任何大型 JWT 的有效負載壓縮，而不僅僅是 JWE
聲明斷言（需要具體值）
使用相容的 JSON 解析器（例如 Jackson）時聲明 POJO 編組和解組
基於所需的 JWA 演算法的安全金鑰生成
還有更多…
非緊湊序列化和解析。
此功能可能會在未來版本中實現。歡迎社區貢獻！
如果您在使用 JJWT 時遇到問題，請在提問之前先閱讀本頁上的文件。我們非常努力地確保 JJWT 的文檔是健壯的、按目錄分類的，並且每個版本都是最新的。
如果文件或 API JavaDoc 不夠充分，並且您有可用性問題或對某些內容感到困惑，請在此處提出您的問題。然而：
請不要創建 GitHub 問題來提出問題。
我們使用 GitHub Issues 來追蹤需要更改 JJWT 設計和/或程式碼庫的可操作工作。如果您有可用性問題，請在此處提出您的問題，如有必要，我們可以將其轉換為問題。
如果建立的 GitHub 問題並不代表 JJWT 程式碼庫的可操作工作，它將立即關閉。
如果您沒有可用性問題並認為您有合法的錯誤或功能請求，請先在此處討論。請先快速搜尋一下，看看是否有與您相關的現有討論，如有必要，請加入該現有討論。
如果您想自己幫助修復錯誤或實現新功能，請在開始任何工作之前閱讀接下來的「貢獻」部分。
修復 JJWT 核心程式碼（文件、JavaDoc、拼字錯誤、測試案例等）以外的任何內容的簡單 Pull 請求總是受到讚賞，並且很有可能被快速合併。請發送給他們！
但是，如果您想要或感覺需要更改 JJWT 的功能或核心程式碼，請在開始處理之前先啟動新的 JJWT 討論並討論您所需的更改，然後再發出拉取請求。
如果您真誠且真正欣賞的拉取請求可能與專案的目標、設計期望或計劃的功能不符，那麼拒絕它將是一種恥辱。遺憾的是，我們過去不得不拒絕大型 PR，因為它們與專案或設計預期不同步 - 所有這些都是因為 PR 作者在製定解決方案之前沒有先與團隊聯繫。
因此，請先建立新的 JJWT 討論進行討論，然後我們可以輕鬆地將討論轉換為問題，然後查看是否（或如何）有必要提出 PR。謝謝你！
如果您想提供幫助，但不知道從哪裡開始，請訪問“需要幫助的問題”頁面並選擇其中的任何問題，我們將很樂意討論並回答問題評論中的問題。
如果其中任何一個對您沒有吸引力，不用擔心！根據上述有關貢獻拉取請求的注意事項，您想提供的任何幫助將不勝感激。如果您不確定，請先討論或提出問題。 :)
JSON Web Token (JWT) 是一種通用的基於文字的訊息傳遞格式，用於以緊湊且安全的方式傳輸訊息。與普遍看法相反，JWT 不僅適用於在網路上發送和接收身份令牌 - 即使這是最常見的用例。 JWT 可用作任何類型資料的訊息。
最簡單形式的 JWT 包含兩個部分：
JWT 中的主要數據，稱為payload ，以及
具有名稱/值對的 JSON Object ，表示有關payload和訊息本身的元數據，稱為header 。
JWT payload絕對可以是任何東西 - 任何可以表示為位元組數組的東西，例如字串、圖像、文件等。
但由於 JWT header是 JSON Object ，因此 JWT payload也可以是 JSON Object像是有意義的。在許多情況下，開發人員喜歡 JSON 格式的payload ，表示有關使用者或電腦或類似身分概念的資料。以這種方式使用時， payload稱為 JSON Claims對象，該對像中的每個名稱/值對稱為claim - “聲明”中的每個資訊都與身份有關。
雖然「聲明」有關身份的某些資訊很有用，但實際上任何人都可以做到這一點。重要的是，您可以透過驗證這些聲明來自您信任的人或電腦來信任這些聲明。
JWT 的一個很好的功能是可以透過多種方式保護它們。 JWT 可以進行加密簽章（使其成為我們所說的 JWS）或加密（使其成為 JWE）。這為 JWT 增加了一層強大的可驗證性 - JWS 或 JWE 接收者可以透過驗證簽名或解密簽名來高度相信它來自他們信任的人。正是這種可驗證性功能使 JWT 成為發送和接收安全訊息（例如身分聲明）的良好選擇。
最後，帶有空格的 JSON 對於人類可讀性來說很好，但它並不能成為一種非常有效的訊息格式。因此，JWT 可以被壓縮（甚至壓縮）為最小表示形式 - 基本上是 Base64URL 編碼的字串 - 因此它們可以更有效地在網路上傳輸，例如在 HTTP 標頭或 URL 中。
一旦有了payload和header ，它們如何壓縮以進行網路傳輸，最終的 JWT 實際是什麼樣子的？讓我們使用一些偽代碼來了解該過程的簡化版本：
假設我們有一個帶有 JSON header和簡單文字訊息負載的 JWT：
標頭
{
“alg”：“無”
}有效負載
智慧的真正標誌不是知識而是想像。
刪除 JSON 中所有不必要的空格：
String header = ' {"alg":"none"} '
String payload = ' The true sign of intelligence is not knowledge but imagination. '取得每個位元組的 UTF-8 位元組和 Base64URL 編碼：
String encodedHeader = base64URLEncode( header . getBytes( " UTF-8 " ) )
String encodedPayload = base64URLEncode( payload . getBytes( " UTF-8 " ) )使用句點（“.”）字元連接編碼的標頭和聲明：
String compact = encodedHeader + ' . ' + encodedPayload + ' . '最終連接的compact JWT 字串如下所示：
eyJhbGciOiJub25lIn0.VGhlIHRydWUgc2lnbiBvZiBpbnRlbGxpZ2VuY2UgaXMgbm90IGtub3dsZWRnZSBidXQgaW1hZ2luYXRpb24u。
這被稱為「不受保護」的 JWT，因為不涉及安全性 - 沒有數位簽章或加密來「保護」JWT 以確保它不能被第 3 方更改。
如果我們想要對緊湊形式進行數位簽名，以便至少可以保證在我們檢測到數據的情況下沒有人會更改數據，那麼我們必須執行更多步驟，如下所示。
下一個範例將使用可能最常見的有效負載類型，而不是純文字有效負載 - 包含有關特定身分的資訊的 JSON 聲明Object 。我們還將對 JWT 進行數位簽名，以確保第三方無法在我們不知情的情況下對其進行更改。
假設我們有一個 JSON header和一個聲明payload ：
標頭
{
"alg" : " HS256 "
}有效負載
{
"sub" : " Joe "
}在本例中， header指示將使用HS256 （使用 SHA-256 的 HMAC）演算法對 JWT 進行加密簽章。此外， payload JSON 物件有一個聲明， sub的值為Joe 。
說明書中有許多標準權利要求，稱為註冊權利要求， sub （「主題」）就是其中之一。
刪除兩個 JSON 物件中所有不必要的空格：
String header = ' {"alg":"HS256"} '
String claims = ' {"sub":"Joe"} '取得它們的 UTF-8 位元組並對其進行 Base64URL 編碼：
String encodedHeader = base64URLEncode( header . getBytes( " UTF-8 " ) )
String encodedClaims = base64URLEncode( claims . getBytes( " UTF-8 " ) )使用句點字元“.”連接編碼的標頭和聲明分隔符號：
String concatenated = encodedHeader + ' . ' + encodedClaims使用足夠強的加密金鑰或私鑰以及您選擇的簽章演算法（我們將在此處使用 HMAC-SHA-256），並對連接的字串進行簽署：
SecretKey key = getMySecretKey()
byte [] signature = hmacSha256( concatenated, key )由於簽章始終是位元組數組，因此對簽章進行 Base64URL 編碼，並將其連接到帶有句點字元“.”的concatenated字串。分隔符號：
String compact = concatenated + ' . ' + base64URLEncode( signature )就這樣，最終的compact字串如下所示：
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJKb2UifQ.1KP0SsvENi7Uz1oQc07aXTL7kpQG5jBNIybqr60AlD4
這稱為“JWS”——簽名JWT 的縮寫。
當然，沒有人願意在程式碼中手動執行此操作，更糟糕的是，如果出現任何錯誤，可能會引入嚴重的安全問題和弱點。因此，JJWT 的創建是為了為您處理所有這些：JJWT 完全自動化 JWS 的創建以及 JWS 的解析和驗證。
到目前為止，我們已經看到了未受保護的 JWT 和加密簽署的 JWT（稱為“JWS”）。這兩者固有的特點之一是，任何人都可以看到其中的所有資訊 - 標頭和有效負載中的所有資料都是公開可見的。 JWS 只是確保資料沒有被任何人更改 - 它不會阻止任何人查看它。很多時候，這很好，因為其中的數據不是敏感資訊。
但是，如果您需要在 JWT 中表示被視為敏感資訊的資訊（可能是某人的郵政地址、社會安全號碼或銀行帳號），該怎麼辦？
在這些情況下，我們需要一個完全加密的 JWT，簡稱為「JWE」。 JWE 使用加密技術來確保有效負載保持完全加密和經過身份驗證，因此未經授權的各方無法查看其中的數據，也無法在不被發現的情況下更改數據。具體來說，JWE 規範要求使用關聯資料演算法的身份驗證加密來完全加密和保護資料。
AEAD 演算法的完整概述超出了本文檔的範圍，但以下是使用這些演算法的最終緊湊型 JWE 的範例（換行符僅供閱讀）：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0。 6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ。 AxY8DCtDaGlsbGljb3RoZQ。 KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY。 U0m_YmjN04DJvceFICbCVQ
接下來我們將介紹如何在專案中安裝 JJWT，然後我們將了解如何使用 JJWT 流暢的 API 而不是危險的字串操作來快速安全地建立 JWT、JWS 和 JWE。
使用您最喜歡的 Maven 相容建置工具從 Maven Central 提取依賴項。
如果您使用 JDK 專案或 Android 項目，相依性可能會略有不同。
如果您正在建置（非 Android）JDK 項目，您將需要定義以下相依性：
< dependency >
< groupId >io.jsonwebtoken</ groupId >
< artifactId >jjwt-api</ artifactId >
< version >0.12.6</ version >
</ dependency >
< dependency >
< groupId >io.jsonwebtoken</ groupId >
< artifactId >jjwt-impl</ artifactId >
< version >0.12.6</ version >
< scope >runtime</ scope >
</ dependency >
< dependency >
< groupId >io.jsonwebtoken</ groupId >
< artifactId >jjwt-jackson</ artifactId > <!-- or jjwt-gson if Gson is preferred -->
< version >0.12.6</ version >
< scope >runtime</ scope >
</ dependency >
<!-- Uncomment this next dependency if you are using:
- JDK 10 or earlier, and you want to use RSASSA-PSS (PS256, PS384, PS512) signature algorithms.
- JDK 10 or earlier, and you want to use EdECDH (X25519 or X448) Elliptic Curve Diffie-Hellman encryption.
- JDK 14 or earlier, and you want to use EdDSA (Ed25519 or Ed448) Elliptic Curve signature algorithms.
It is unnecessary for these algorithms on JDK 15 or later.
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk18on</artifactId> or bcprov-jdk15to18 on JDK 7
<version>1.76</version>
<scope>runtime</scope>
</dependency>
--> dependencies {
implementation ' io.jsonwebtoken:jjwt-api:0.12.6 '
runtimeOnly ' io.jsonwebtoken:jjwt-impl:0.12.6 '
runtimeOnly ' io.jsonwebtoken:jjwt-jackson:0.12.6 ' // or 'io.jsonwebtoken:jjwt-gson:0.12.6' for gson
/*
Uncomment this next dependency if you are using:
- JDK 10 or earlier, and you want to use RSASSA-PSS (PS256, PS384, PS512) signature algorithms.
- JDK 10 or earlier, and you want to use EdECDH (X25519 or X448) Elliptic Curve Diffie-Hellman encryption.
- JDK 14 or earlier, and you want to use EdDSA (Ed25519 or Ed448) Elliptic Curve signature algorithms.
It is unnecessary for these algorithms on JDK 15 or later.
*/
// runtimeOnly 'org.bouncycastle:bcprov-jdk18on:1.76' // or bcprov-jdk15to18 on JDK 7
}Android 專案需要定義以下相依性和 Proguard 排除項，以及選購的 BouncyCastle Provider ：
將依賴項新增至您的專案：
dependencies {
api( ' io.jsonwebtoken:jjwt-api:0.12.6 ' )
runtimeOnly( ' io.jsonwebtoken:jjwt-impl:0.12.6 ' )
runtimeOnly( ' io.jsonwebtoken:jjwt-orgjson:0.12.6 ' ) {
exclude( group : ' org.json ' , module : ' json ' ) // provided by Android natively
}
/*
Uncomment this next dependency if you want to use:
- RSASSA-PSS (PS256, PS384, PS512) signature algorithms.
- EdECDH (X25519 or X448) Elliptic Curve Diffie-Hellman encryption.
- EdDSA (Ed25519 or Ed448) Elliptic Curve signature algorithms.
** AND ALSO ensure you enable the BouncyCastle provider as shown below **
*/
// implementation('org.bouncycastle:bcprov-jdk18on:1.76') // or bcprov-jdk15to18 for JDK 7
}您可以使用以下 Android Proguard 排除規則：
-keepattributes 內部類
-keep 類別 io.jsonwebtoken.** { *; }
-keepnames 類別 io.jsonwebtoken.* { *; }
-keepnames 介面 io.jsonwebtoken.* { *; }
-keep 類別 org.bouncycastle.** { *; }
-keepnames 類別 org.bouncycastle.** { *; }
-dontwarn org.bouncycastle.** 如果您想使用 JWT RSASSA-PSS 演算法（即PS256 、 PS384和PS512 ）、EdECDH（ X25512或X448 ）橢圓曲線 Diffie-Hellman 加密、EdDSA（ Ed25519或Ed448 ）簽名演算法，或者您只是想確保您的 Android應用程式正在運行BouncyCastle 的更新版本，您將需要：
取消註解 BouncyCastle 依賴項，如上面相依性部分所述。
將舊版 Android 自訂BC提供者替換為更新後的提供者。
提供者註冊需要在應用程式生命週期的早期完成，最好在應用程式的主Activity類別中作為靜態初始化區塊完成。例如：
class MainActivity : AppCompatActivity () {
companion object {
init {
Security .removeProvider( " BC " ) // remove old/legacy Android-provided BC provider
Security .addProvider( BouncyCastleProvider ()) // add 'real'/correct BC provider
}
}
// ... etc ...
}請注意，上述 JJWT 依賴項聲明都只有一個編譯時依賴項，其餘的都聲明為執行時間依賴項。
這是因為 JJWT 的設計使您僅依賴明確設計供您在應用程式中使用的 API，而所有其他內部實作細節（可能會在沒有警告的情況下更改）都被降級為僅運行時依賴項。如果您想確保 JJWT 的穩定使用和隨著時間的推移進行升級，這是非常重要的一點：
JJWT 保證除 |
這樣做是為了讓您受益：非常小心地管理jjwt-api .jar 並確保它包含您需要的內容並儘可能保持向後相容，以便您可以在編譯範圍內安全地依賴它。運行時jjwt-impl .jar 策略為 JJWT 開發人員提供了根據需要隨時更改內部套件和實現的靈活性。這有助於我們更快、更有效率地實現功能、修復錯誤以及向您發布新版本。
大多數複雜性都隱藏在基於建構器的方便且可讀的流暢介面後面，非常適合依靠 IDE 自動完成來快速編寫程式碼。這是一個例子：
import io . jsonwebtoken . Jwts ;
import io . jsonwebtoken . security . Keys ;
import java . security . Key ;
// We need a signing key, so we'll create one just for this example. Usually
// the key would be read from your application configuration instead.
SecretKey key = Jwts . SIG . HS256 . key (). build ();
String jws = Jwts . builder (). subject ( "Joe" ). signWith ( key ). compact ();那是多麼容易啊！
在這種情況下，我們是：
建立一個 JWT，將註冊的聲明sub （主題）設定為Joe 。我們那時
使用適合 HMAC-SHA-256 演算法的金鑰對 JWT進行簽署。最後，我們是
將其壓縮為最終的String形式。簽名的 JWT 稱為“JWS”。
產生的jws字串如下所示：
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJKb2UifQ.1KP0SsvENi7Uz1oQc07aXTL7kpQG5jBNIybqr60AlD4
現在讓我們驗證 JWT（您應該始終丟棄與預期簽名不匹配的 JWT）：
assert Jwts . parser (). verifyWith ( key ). build (). parseSignedClaims ( jws ). getPayload (). getSubject (). equals ( "Joe" );這裡發生了兩件事。先前的key用於驗證 JWT 的簽章。如果無法驗證 JWT，則會拋出SignatureException （擴展JwtException ）。假設 JWT 已驗證，我們解析聲明並斷言主題設為Joe 。您一定會喜歡那些充滿衝擊力的俏皮話程式碼！
筆記 | 類型安全 JWT：要取得類型安全的 |
但是如果解析或簽章驗證失敗怎麼辦？您可以捕獲JwtException並做出相應的反應：
try {
Jwts . parser (). verifyWith ( key ). build (). parseSignedClaims ( compactJws );
//OK, we can trust this JWT
} catch ( JwtException e ) {
//don't trust the JWT!
}現在我們已經快速入門如何建立和解析 JWT，接下來讓我們深入介紹 JJWT 的 API。
您可以如下建立 JWT：
使用Jwts.builder()方法建立JwtBuilder實例。
可以根據需要設定任何header參數。
呼叫建構器方法來設定有效負載內容或聲明。
如果您想要對 JWT 進行數位簽章或加密，可以選擇呼叫signWith或encryptWith方法。
呼叫compact()方法來產生結果緊密的JWT字串。
例如：
String jwt = Jwts . builder () // (1)
. header () // (2) optional
. keyId ( "aKeyId" )
. and ()
. subject ( "Bob" ) // (3) JSON Claims, or
//.content(aByteArray, "text/plain") // any byte[] content, with media type
. signWith ( signingKey ) // (4) if signing, or
//.encryptWith(key, keyAlg, encryptionAlg) // if encrypting
. compact (); // (5) JWT payload可以是byte[]內容（透過content ）或JSON 宣告（例如subject 、 claims等），但不能同時是兩者。
可以使用數位簽章 ( signWith ) 或加密 ( encryptWith )，但不能同時使用兩者。
不受保護的 JWT ：如果您不使用 |
JWT 標頭是一個 JSON Object ，它提供有關內容、格式以及與 JWT payload相關的任何加密操作的元資料。 JJWT 提供了多種設定整個標頭和/或多個單獨標頭參數（名稱/值對）的方法。
設定一個或多個 JWT 標頭參數（名稱/值對）的最簡單且建議的方法是根據需要使用JwtBuilder的header()建構器，然後呼叫其and()方法傳回JwtBuilder進行進一步配置。例如：
String jwt = Jwts . builder ()
. header () // <----
. keyId ( "aKeyId" )
. x509Url ( aUri )
. add ( "someName" , anyValue )
. add ( mapValues )
