【ITニュース解説】What is JWT? How do Secret, Public, Private Keys actually work?

Webサービスやアプリケーションにおいて、ユーザーが誰であるかを確認し、そのユーザーが利用できる機能や情報へのアクセスを許可する「認証」の仕組みは、システムの安全性と信頼性を保つ上で非常に重要だ。JSON Web Token（JWT）は、この認証のプロセスで、クライアント（例えばウェブブラウザやモバイルアプリ）とサーバーの間で安全に情報をやり取りするための優れた方法の一つである。

JWTは、通常「ヘッダー」「ペイロード」「署名」という三つの部分から構成される。ヘッダーには、トークンを暗号化するためにどのアルゴリズムが使われたかや、トークンの種類が記載されている。ペイロードには、ユーザーの識別子、ユーザー名、トークンの発行日時、有効期限など、実際のユーザー情報やシステムに関するデータが格納される。そして、署名は、このJWTが途中で改ざんされていないことや、正当な発行元から送られたものであることを検証するために使われる、いわばトークンの「封印」のようなものだ。

認証の基本的な流れは、まずユーザーがログイン情報を提供し、サーバーがその情報を使ってJWTを発行する。ユーザーはこのJWTを受け取り、その後のAPIリクエスト（例えば、データ取得や更新）のたびに、このJWTを添付してサーバーに送信する。サーバーは受け取ったJWTの署名を検証し、トークンが有効で改ざんされていないと確認できれば、リクエストされた処理を実行する。このようにして、JWTはユーザーの身元を保証し、セキュアな通信を可能にするパスポートのような役割を果たす。

JWTを利用した認証アプローチには、主に二つの主要な方法がある。一つは「秘密鍵（シークレットキー）方式」、もう一つは「公開鍵と秘密鍵（RSA鍵ペア）方式」だ。

秘密鍵方式は、一つの共通の「秘密鍵」を使ってJWTの署名と検証を行う「対称鍵暗号」の仕組みを用いる。このアプローチでは、トークンを発行するサーバーも、受け取ったトークンを検証するサーバーも、全く同じ秘密鍵を共有して使用する。例えば、Node.jsのプログラムで安全な秘密鍵を生成し、それを環境変数として設定する。サーバーは、この秘密鍵を使ってユーザー情報を含むJWTを生成し、その後のAPIリクエストで送られてきたトークンも、同じ秘密鍵で署名を検証する。この方式は、一つのアプリケーションで認証が完結する場合や、同じ組織内の内部APIなど、鍵の共有範囲が限定的なシンプルな環境に適している。実装が比較的簡単で、トークンの検証速度も速いという利点があるが、もし秘密鍵が外部に漏洩してしまうと、誰でも本物と偽のJWTを自由に生成したり、既存のJWTを改ざんしたりできてしまうため、秘密鍵の厳重な管理が最も重要となる。

一方、公開鍵と秘密鍵方式は、「非対称鍵暗号」の仕組みを利用する。この方法では、「秘密鍵（プライベートキー）」と「公開鍵（パブリックキー）」という、ペアになった二つの異なる鍵を使用する。JWTを発行する側は「秘密鍵」を使ってトークンに署名し、そのトークンを受け取って検証する側は、対応する「公開鍵」を使って署名の正当性を確認する。この二つの鍵は数学的にペアになっているため、秘密鍵で署名されたトークンは、そのペアである公開鍵でしか正しく検証できない。しかし、公開鍵を誰にでも公開しても、そこから秘密鍵を推測することは極めて困難であり、セキュリティ上のリスクは低い。このアプローチは、複数の異なるシステム（例えば、マイクロサービスと呼ばれる小さな独立したサービス群）が連携する分散システムや、外部のサードパーティサービスとの連携、あるいはトークンの発行元と検証元が物理的に分離しているような、より高度なセキュリティと柔軟性が求められる環境で特に有効だ。

この方式では、opensslのようなツールを使って秘密鍵と公開鍵のペアを生成する。秘密鍵はトークンを生成するシステムで厳重に保管され、決して外部に公開されない。一方、公開鍵はトークンを検証する各サーバーに安全に配布され、環境変数として設定される。トークンの生成は専用の認証サービスや外部システムが行い、その生成されたトークンがユーザーを介して検証側のAPIサーバーへ送られる。検証側のサーバーは、手元にある公開鍵を使って、受け取ったトークンの署名が正しく、かつ秘密鍵によって生成された本物であることを確認する。この方式の大きな利点は、秘密鍵が検証サーバーには置かれないため、検証サーバーが攻撃されたとしても秘密鍵が漏洩するリスクを低減できる点にある。また、公開鍵を複数の検証サーバーに配布できるため、システムの柔軟な拡張が可能となる。しかし、鍵ペアの生成や管理、設定が秘密鍵方式に比べて複雑になることや、検証処理がわずかに遅くなる可能性がある点が考慮される。

これら二つのアプローチを比較すると、秘密鍵方式は導入がシンプルで、小規模なシステムや内部向けAPIに素早く適用できる。しかし、鍵の共有範囲が広がるほど、秘密鍵漏洩時のリスクも増大する。対照的に、公開鍵と秘密鍵方式は、分散システムや外部連携において、トークン発行と検証の役割を明確に分離し、秘密鍵の安全性をより高く保つことができるため、堅牢なセキュリティを実現する。ただし、設定の複雑さが増す。どちらの方式を選択するかは、構築するシステムの規模、求められるセキュリティレベル、そして管理体制を総合的に考慮して判断する必要がある。

どちらのアプローチを選ぶにしても、共通して適用すべきセキュリティのベストプラクティスがいくつかある。最も重要なのは、秘密鍵やプライベートキーといった機密性の高い情報は、決してソースコードと共にバージョン管理システムに保存せず、環境変数や専用の鍵管理サービスのような、より安全な方法で保管することだ。また、生成するJWTには必ず有効期限を設定し、期限切れのトークンが不正に利用されないよう、定期的に新しいトークンに更新する仕組みを導入することが望ましい。APIとの通信は常にHTTPSプロトコルを使って暗号化し、認証エンドポイントに対しては、過度なリクエストを防ぐためにレート制限を設けることも重要である。さらに、JWTのペイロードには、必要最小限のユーザー識別子、ロール、権限などの情報のみを含めることで、漏洩時の影響を最小限に抑えることができる。これらの対策を講じることで、システムのセキュリティレベルを大きく高めることができる。

もしトークン認証の過程で問題が発生した場合は、一般的な原因として、公開鍵が正しく設定されていないこと、あるいは使われている暗号化アルゴリズム（例えば、秘密鍵方式のHS256と公開鍵方式のRS256）がトークンとサーバーで一致していないこと、トークンの有効期限が切れていること、または署名が無効である（つまり、対応する鍵ペアが正しくない）ことなどが挙げられる。このような状況では、システムのデバッグログを詳しく確認したり、jwt.ioのようなオンラインツールを使って発行されたトークンの内容を解析したりすることで、問題の原因を特定しやすくなる。

システム開発においては、JWTの各認証アプローチの特性を深く理解し、自身のアプリケーションやサービスの要件に最も合致する適切な方法を選択することが成功の鍵となる。鍵の安全な管理、環境変数の適切な設定、そしてトークンの生成と検証プロセスの確立に加え、HTTPSの適用やトークンの有効期限設定といったセキュリティ対策を徹底することで、ユーザーに安全で信頼性の高いサービスを提供できるシステムを構築することが可能となる。