【ITニュース解説】How JWT Signing Keys Are Issued and Rotated (and Why 'alg' Deserves Distrust)
2026年10月09日に「Dev.to」が公開したITニュース「How JWT Signing Keys Are Issued and Rotated (and Why 'alg' Deserves Distrust)」について初心者にもわかりやすく解説しています。
ITニュース概要
JWTは秘密鍵で署名し、公開鍵で改ざんがないか検証する。公開鍵はJWKSで提供され、鍵ID(kid)で識別する。鍵更新時は、古い鍵の期限切れまで新しい鍵と併用し、途切れないようにする。検証アルゴリズムは固定し、JWTの`alg`ヘッダーは信頼せず利用しない。秘密鍵の厳重な管理が不可欠だ。
ITニュース解説
システムエンジニアを目指す上で、Webアプリケーションのセキュリティは非常に重要なテーマであり、その中でも「JWT(JSON Web Token)」は認証や認可の仕組みで広く使われているため、その仕組みと安全な運用方法を理解することは必須である。
JWTは「ヘッダー(header)」「ペイロード(payload)」「署名(signature)」という、三つの部分がピリオドで区切られた形式を持つ文字列で構成される。この中で最も重要で、トークンの「本物らしさ」を保証するのが署名である。署名は、ヘッダーとペイロードの内容に基づいて計算され、たとえ一つの文字でも変更されると、署名が無効になるように設計されている。この仕組みこそが、情報の改ざんを防ぎ、その情報が確かに意図した発行元から来たものであることを保証する。
署名を作るためには「鍵のペア」が使われる。一つは「秘密鍵」で、これは署名を作成するためにのみ使われ、発行元(トークンを作るシステム)の内部に厳重に保管され、決して外部に出ることはない。もう一つは「公開鍵」で、これは署名の正当性を検証するために使われる。公開鍵は名前の通り公開されており、誰でもアクセスできる。つまり、トークンを発行できるのは秘密鍵を持つ発行元だけであり、そのトークンが本物であるかを検証できるのは、公開鍵を知っている誰でも可能、という関係が成り立つ。公開鍵は検証のみに利用され、偽造トークンを作成することはできない。
システムが公開鍵を他のシステムに提供する方法として、「JWKS(JSON Web Key Set)」という仕組みがある。これは、公開鍵をJSON形式で記述し、特定のURL(通常は「.well-known/jwks.json」のような形式)で公開するエンドポイントである。各公開鍵には「kid(キーID)」という識別子が付けられており、発行されたJWTトークンにも、どの「kid」の鍵で署名されたかという情報が含まれている。トークンを受け取った検証システムは、この「kid」情報を使ってJWKSエンドポイントから適切な公開鍵を取得し、署名を検証する。
鍵は安全のために定期的に更新(ローテーション)する必要がある。しかし、このローテーションは慎重に行う必要がある。新しい鍵を導入する際は、新しい公開鍵を公開すると同時に、古い公開鍵も一定期間、JWKSエンドポイントに保持し続けるのが正しい方法である。この「オーバーラップ期間」を設けることで、古い鍵で署名された既存のトークンがまだ有効期限内である間も、引き続き検証が可能になる。もし古い公開鍵を早々にJWKSから削除してしまうと、現在利用されている古いトークンがすべて一斉に無効となり、システムに大きな混乱を招くことになるため注意が必要だ。
JWTのセキュリティにおいて特に警戒すべき点として、トークン自身のヘッダーに含まれる「alg(アルゴリズム)」フィールドの扱いがある。このフィールドは、署名に使われた暗号アルゴリズムを示すものだが、検証システムはこの情報を決して信用してはならない。悪意のある攻撃者は、この「alg」フィールドを「none」に書き換えることで、署名が全く存在しない、あるいは安全ではない方法で検証されるように誘導しようとする可能性がある。これを「アルゴリズム混同攻撃」と呼ぶ。正しい対策は、検証システム側で、あらかじめ安全と認められたアルゴリズム(例えばRS256やES256など)のホワイトリストを固定で持ち、トークンの「alg」フィールドに関わらず、この許可リストに含まれるアルゴリズムのみを使って検証することである。RFC 8725(JWTのベストプラクティス)でも、この原則が明確に推奨されている。
実際に、この署名鍵の管理不備が原因で重大なセキュリティインシデントが発生した事例もある。2023年には「Storm-0558」と呼ばれる事件で、本来なら特定のシステム内でしか使われるべきでない署名鍵が外部に漏洩し、攻撃者がその鍵を使って偽造JWTトークンを作成した。その結果、20以上の組織でメールが読み取られるという被害が生じた。この事例は、漏洩した署名鍵が、それを信頼する全てのシステムにとっての「マスターキー」となりうる危険性を示している。
これらの教訓を踏まえると、システムエンジニアとして以下の実践項目を守ることが極めて重要となる。まず、鍵は常に秘密鍵と公開鍵のペアで生成し、特に秘密鍵はそれを生成したサービスから絶対に外部に出さないようにする。次に、公開鍵をJWKSエンドポイントで公開する際は、各鍵にユニークな「kid」を付与し、発行する全てのトークンにもこの「kid」情報を含める。鍵のローテーションは、新しい鍵と古い鍵の公開鍵を一時的に併存させる「オーバーラップ」方式で行い、古いトークンが全て期限切れになるまで古い公開鍵を維持する。そして最も重要な点として、JWTの署名アルゴリズムは固定のホワイトリストで管理し、「none」のような危険なアルゴリズムを拒否すること。トークン自身の「alg」フィールドに依存して検証方法を決定するような実装は決して行ってはならない。
これらの厳格なセキュリティプラクティスを守ることで、JWTを利用したシステムは安全性を保ち、ユーザーの信頼を得ることができるだろう。