jjwt
0.12.6
JJWT は、JVM および Android 上で JSON Web トークン (JWT) と JSON Web キー (JWK) を作成および検証するための、最も使いやすく理解しやすいライブラリを目指しています。
JJWT は、JOSE Working Group 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 Curve アルゴリズムと 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 を使用した MGF1 1 |
| SHA-384 を使用した RSASSA-PSS および SHA-384 を使用した MGF1 1 |
| SHA-512 を使用した RSASSA-PSS および SHA-512 を使用した MGF1 1 |
| エドワーズ曲線デジタル署名アルゴリズム2 |
1.実行時クラスパスに Java 11 または互換性のある JCA プロバイダー (BouncyCastle など) が必要です。
２ ．実行時クラスパスに 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 一時的な静的鍵合意 |
| 「A128KW」でラップされた Concat KDF および CEK を使用する ECDH-ES |
| 「A192KW」でラップされた Concat KDF および CEK を使用する ECDH-ES |
| 「A256KW」でラップされた Concat KDF および CEK を使用する ECDH-ES |
| 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 など) が必要です。
２ ．実行時クラスパスに Java 15 または互換性のある JCA プロバイダー (BouncyCastle など) が必要です。
仕様を超えた利便性の向上
JWE だけでなく、大規模な JWT のペイロード圧縮
クレーム アサーション (特定の値が必要)
互換性のある JSON パーサー (例: Jackson) を使用する場合、POJO マーシャリングとアンマーシャリングを要求します。
必要な JWA アルゴリズムに基づいたセキュア キーの生成
さらに…
非コンパクトなシリアル化と解析。
この機能は将来のリリースで実装される可能性があります。コミュニティへの貢献は大歓迎です!
JJWT の使用に問題がある場合は、質問する前にまずこのページのドキュメントをお読みください。私たちは、JJWT のドキュメントが堅牢で、目次で分類され、リリースごとに最新であることを保証するために非常に努力しています。
ドキュメントや API JavaDoc だけでは十分ではなく、使いやすさについて質問がある場合、または何か混乱している場合は、ここで質問してください。しかし：
質問するために GitHub 問題を作成しないでください。
私たちは GitHub Issues を使用して、JJWT の設計やコードベースの変更を必要とする実用的な作業を追跡します。ユーザビリティに関する質問がある場合は、代わりにここで質問してください。必要に応じて問題に変換できます。
JJWT のコードベースの実用的な作業を示さない GitHub の問題が作成された場合、その問題は直ちに閉じられます。
ユーザビリティに関する質問がなく、正当なバグや機能のリクエストがあると思われる場合は、まずここで議論してください。まず簡単な検索を行って、自分のディスカッションに関連する既存のディスカッションが既に存在するかどうかを確認し、必要に応じてその既存のディスカッションに参加してください。
バグの修正や新機能の実装を自分で手伝いたいと思われる場合は、作業を開始する前に、次の「貢献」セクションをお読みください。
JJWT コア コード以外 (ドキュメント、JavaDoc、タイプミス、テスト ケースなど) を修正する単純なプル リクエストは常に高く評価され、すぐにマージされる可能性が高くなります。ぜひ送ってください！
ただし、JJWT の機能やコア コードを変更したい、または変更する必要があると感じた場合は、作業を開始する前に、新しい JJWT ディスカッションを開始し、必要な変更について話し合うことなく、プル リクエストを発行しないでください。
本気で心から感謝しているプルリクエストが、プロジェクトの目標、設計上の期待、または計画されている機能と一致しない可能性がある場合、それを拒否するのは残念なことです。悲しいことに、私たちは過去にプロジェクトや設計の期待と同期していないという理由で大規模な PR を拒否しなければならなかったことがあります。すべては、PR 作成者がソリューションに取り組む前に最初にチームに確認しなかったためです。
したがって、最初に新しい JJWT ディスカッションを作成して議論してください。その後、ディスカッションを問題に簡単に変換して、PR が正当であるかどうか (またはどのように) を確認できるかを確認できます。ありがとう！
助けたいがどこから始めればよいかわからない場合は、「助けてほしい問題」ページにアクセスして、そこから問題を選択してください。問題のコメントで喜んで議論し、質問に答えます。
これらのどれかがあなたにとって魅力的でないとしても、心配する必要はありません。プル リクエストの投稿に関する上記の注意事項に基づいて、ご協力をお願いいたします。不明な点がある場合は、まずお気軽にご相談またはご質問ください。 :)
JSON Web Token (JWT) は、コンパクトかつ安全な方法で情報を送信するための汎用のテキストベースのメッセージング形式です。一般に信じられていることに反して、JWT は、たとえそれが最も一般的な使用例であっても、Web 上で ID トークンを送受信するのに役立つだけではありません。 JWT は、あらゆる種類のデータのメッセージとして使用できます。
最も単純な形式の JWT には、次の 2 つの部分が含まれます。
JWT 内の主要なデータpayloadと呼ばれます)、
payloadとメッセージ自体に関するメタデータを表す名前と値のペアを持つ JSON Object headerと呼ばれます)。
JWT payload文字列、画像、ドキュメントなど、バイト配列として表現できるものであれば何でも構いません。
ただし、JWT headerは JSON Objectであるため、JWT payloadも JSON Objectであることは当然です。多くの場合、開発者はpayloadユーザーやコンピューター、または同様の ID 概念に関するデータを表す JSON であることを好みます。この方法で使用される場合、 payloadは JSON Claimsオブジェクトと呼ばれ、そのオブジェクト内の各名前と値のペアはclaimと呼ばれます。つまり、そのオブジェクト内の各情報は ID に関する何かを「クレーム」します。
そして、アイデンティティについて何かを「主張」することは便利ですが、実際には誰でもそれを行うことができます。重要なのは、その主張が信頼できる人物またはコンピュータからのものであることを確認して、その主張を信頼することです。
JWT の優れた特徴は、さまざまな方法でセキュリティを保護できることです。 JWT は、暗号化して署名したり (JWS と呼ぶものにする)、暗号化する (JWE にする) ことができます。これにより、JWT に検証可能性の強力な層が追加されます。JWS または JWE 受信者は、署名を検証するか復号化することで、信頼できる人から送信されたものであるという高い信頼性を得ることができます。この検証可能性の特徴により、ID クレームなどの安全な情報を送受信する場合に JWT が適切な選択肢となります。
最後に、人間が読みやすいように空白を含む JSON は優れていますが、あまり効率的なメッセージ形式にはなりません。したがって、JWT は最小限の表現 (基本的に Base64URL でエンコードされた文字列) に圧縮(さらには圧縮) できるため、HTTP ヘッダーや URL など、Web 上でより効率的に送信できます。
payloadとheader取得したら、Web 送信用にそれらはどのように圧縮されるのでしょうか。また、最終的な 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 を「保護」するためのデジタル署名や暗号化がありません。
少なくとも、データを検出することなく誰もデータを変更しないことを保証できるように、コンパクトなフォームにデジタル署名したい場合は、次に示す手順をさらにいくつか実行する必要があります。
次の例では、プレーン テキスト ペイロードの代わりに、おそらく最も一般的なタイプのペイロード、つまり特定の ID に関する情報を含む JSON クレームObject使用します。また、JWT にデジタル署名して、第三者が知らないうちに変更できないようにします。
JSON headerとクレームpayloadがあると仮定します。
ヘッダ
{
"alg" : " HS256 "
}ペイロード
{
"sub" : " Joe "
}この場合、 header 、JWT の暗号署名にHS256 (SHA-256 を使用した HMAC) アルゴリズムが使用されることを示します。また、 payload JSON オブジェクトには、値Joeを持つsub 1 つのクレームがあります。
仕様には登録済みクレームと呼ばれる標準クレームが多数あり、 sub (「件名」の意味) はその 1 つです。
両方の 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」と呼ばれます) を見てきました。これら 2 つの両方に固有のことの 1 つは、その中のすべての情報が誰でも見ることができるということです。ヘッダーとペイロードの両方のデータはすべて公開されています。 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 ) 楕円曲線ディフィーヘルマン暗号化、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 依存関係宣言にはすべて、コンパイル時の依存関係が 1 つだけあり、残りは実行時の依存関係として宣言されていることに注意してください。
これは、JJWT が、アプリケーションで使用するために明示的に設計された API のみに依存するように設計されており、その他すべての内部実装の詳細 (警告なしに変更される可能性があります) は実行時のみの依存関係に格下げされるためです。これは、安定した JJWT の使用と長期的なアップグレードを確保したい場合に非常に重要な点です。
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 ();なんと簡単だったでしょうか！
この場合、私たちは次のようになります。
登録されたクレームのsub (Subject) がJoeに設定される JWT を構築します。そのとき私たちは
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" );ここでは 2 つのことが起こっています。以前の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 Claims ( subject 、 claimsなど) のいずれかですが、両方であることはできません。
デジタル署名 ( signWith ) または暗号化 ( encryptWith ) のいずれかを使用できますが、両方を使用することはできません。
保護されていない JWT : |
JWT ヘッダーは、JWT payloadに関連するコンテンツ、形式、および暗号化操作に関するメタデータを提供する JSON Objectです。 JJWT は、ヘッダー全体や複数の個別のヘッダー パラメーター (名前と値のペア) を設定するさまざまな方法を提供します。
1 つ以上の JWT ヘッダー パラメーター (名前と値のペア) を設定する最も簡単で推奨される方法は、必要に応じてJwtBuilderのheader()ビルダーを使用し、そのand()メソッドを呼び出してJwtBuilderに戻ってさらなる構成を行うことです。 。例えば：
String jwt = Jwts . builder ()
. header () // <----
. keyId ( "aKeyId" )
. x509Url ( aUri )
. add ( "someName" , anyValue )
. add ( mapValues )
