【ITニュース解説】JWT vs JWS vs JWE: What’s the Difference & When to Use Each

JSON Web Token（JWT）は、インターネット上で安全に情報をやり取りするための、標準化された形式のデータである。これは、何らかの権限や情報を一時的に証明する「トークン」であり、その中に「クレーム」と呼ばれる情報、例えば「このユーザーは誰か」「何ができるか」「いつまで有効か」といった内容が記述される。このJWTはそれ自体が署名されたり暗号化されたりするわけではなく、あくまで情報を保持する「容器」のようなものだ。JWTの安全性を高めるために、JSON Web Signature（JWS）とJSON Web Encryption（JWE）という二つの技術が使われる。

JWS（JSON Web Signature）は、JWTの「完全性」と「真正性」を保証するために利用される。完全性とは、データが途中で改ざんされていないこと、真正性とは、データが間違いなく特定の発行元から送られてきたことを指す。JWSは、デジタル署名という技術を用いてこれらを実現する。デジタル署名とは、発行者が秘密鍵を使ってデータに電子的な署名を施し、受信者が発行者の公開鍵を使ってその署名が正しいか、データが改ざんされていないかを検証する仕組みだ。これにより、署名されたJWTは、もし途中で誰かに改ざんされると、その署名が無効になるため、受信者は改ざんを検知できる。また、署名に使われた鍵の情報から、信頼できる発行元からのデータであることも確認できる。JWS形式のトークンは、その内容がBase64URLエンコードされているため、誰でも内容を読むことはできるが、改ざんに対しては保護されている。JWSは通常、「ヘッダー」「ペイロード（クレーム部分）」「署名」の3つの部分で構成される。主に、ユーザーのアクセス権限を示すアクセストークンなど、内容が機密性でなくても信頼性が求められる場面で使われる。

一方、JWE（JSON Web Encryption）は、JWTの「機密性」を保証するために利用される。機密性とは、許可された人以外にはデータの内容を見せなくすることだ。JWEでは、トークン内のクレーム情報全体が暗号化されるため、復号するための鍵を持たない限り、誰もその内容を読み取ることができない。JWEは通常、「ヘッダー」「暗号化された鍵」「初期化ベクトル」「暗号文」「認証タグ」の5つの部分で構成される。個人を特定できる情報（PII）や金融情報など、外部に漏れてはならない非常に機密性の高い情報をやり取りする際に不可欠な技術である。JWEもまた、暗号化と同時にデータの完全性も保護する仕組みを備えている。

JWSとJWEはそれぞれ異なる目的を持つため、どちらが「より安全」かという単純な比較はできない。データを隠すことが最優先ならJWEが優れているし、データの改ざん防止と発行元の確認が目的で内容が読まれても問題ないならJWSで十分だ。しかし、もしデータが機密であり、かつそれが信頼できる発行元からのものであることを証明したい場合は、「ネストされたJWT」という方法が使われる。これは、まずJWSでデータを署名し、その署名されたJWS全体をさらにJWEで暗号化するという二重の保護をかける手法である。この方法を用いることで、データの機密性と、発行元の検証および改ざん防止の両方を同時に実現できる。

これらの技術を実際に使う際には、いくつかの重要な概念を理解する必要がある。まず、「アルゴリズム」（alg）は、署名や暗号化にどのような暗号方式を使うかを示すものだ。例えば、署名にはRS256（RSA署名アルゴリズム）、暗号化にはRSA-OAEP-256などが使われる。次に、「キーID」（kid）は、複数の鍵の中からどの鍵を使ったかを示す識別子で、これがあることで、受信側は適切な鍵を選んで検証や復号ができる。そして、「JWKS URI」（jwks_uri）は、発行者が自身の公開鍵をインターネット上で公開している場所のURLだ。受信者はこのURLから公開鍵リスト（JWKS）を取得し、kidと照合して正しい公開鍵を見つけ、署名の検証に使う。また、iss（発行者）、aud（受信者）、exp（有効期限）、nbf（有効開始日時）、iat（発行日時）といった「クレーム」は、セキュリティ上必ず検証すべき項目である。

システム連携では、次のような流れでJWSとJWEが利用される。発行者アプリケーションは、まずユーザーIDや権限などの情報を「クレーム」として準備する。次に、このクレームを署名してJWSを作成する。このJWSには、発行者の署名鍵のkid情報が含まれる。もし機密情報を含む場合は、さらにこのJWS全体を受信者アプリケーションの公開鍵で暗号化してJWEを作成する。このJWEには、受信者アプリケーションが使うべき鍵のkid情報も含まれる。完成したJWEは、ネットワークを通じて受信者アプリケーションに送られる。受信者アプリケーションは、JWEを受け取ると、自身の秘密鍵を使ってJWEを復号する。すると、中に含まれていた元のJWSが取り出される。次に、このJWSのヘッダーから発行者が使った署名鍵のkidを読み取る。受信者は発行者のjwks_uriから公開鍵リスト（JWKS）を取得し、そのkidに一致する公開鍵を見つけ出す。この公開鍵を使って、JWSの署名を検証する。署名が正しければ、トークンが改ざんされておらず、信頼できる発行者からのものであることが確認できる。最後に、JWS内のクレーム情報（ユーザーID、権限、有効期限など）を読み取り、それに基づいて処理を進める。

鍵の管理も非常に大切である。発行者は署名用の秘密鍵を厳重に管理し、その公開鍵をjwks_uriを通じて公開する。受信者も暗号化用の秘密鍵を厳重に管理し、その公開鍵を発行者に提供する。セキュリティ対策として、定期的な鍵のローテーション（新しい鍵への更新）も推奨される。新しい鍵をJWKSに追加し、新しいトークンからその鍵で署名を開始し、古い鍵は古いトークンの有効期限が切れるまで残し、その後削除するという手順で安全に鍵を更新できる。

これらの技術を安全に利用するためのベストプラクティスも存在する。まず、どのような状況でも必ずHTTPS/TLSを使って通信を暗号化することが基本だ。これにより、通信経路での盗聴を防ぐ。次に、トークンを検証する際には、許可された署名・暗号化アルゴリズムのみを受け入れるように設定し、未知のアルゴリズムを拒否することが重要だ。また、トークンに含まれる発行者、受信者、有効期限などのクレームは厳密に検証し、時間のずれを許容する「クロックトレランス」を設定する際も、その許容範囲を小さく保つべきだ。アクセストークンは、万が一漏洩しても被害が最小限になるように、有効期限を短く設定し（通常5分から15分）、長期間有効な「リフレッシュトークン」と組み合わせて使うのが一般的である。そして、個人情報などの機密情報をJWSに直接含めるべきではない。JWSは署名されていても内容は読めてしまうため、機密情報を扱う場合はJWEで暗号化するか、そもそもトークン自体を不透明な識別子として使い、機密情報は別の安全な場所で管理するべきだ。最後に、検証に失敗したトークンのログを記録し、不審な再利用や発行者・受信者情報の不一致がないかなどを常に監視することも、セキュリティを維持する上で欠かせない。

JWSはデータの完全性と発行者の認証を提供し、内容は読めるが改ざんは防げる。JWEはデータの機密性を提供し、内容を暗号化して隠す。そして、もし機密性の高いデータを発行者も明確に認証したい場合には、JWSで署名してからJWEで暗号化する「ネストされたJWT」が最も推奨される方法となる。