【ITニュース解説】Validating OAuth Metadata and JWTs

最新のITシステムでは、異なるサービスが互いに安全に通信することが不可欠だ。特にマイクロサービスアーキテクチャやAPI連携が主流となる中で、ユーザーや別のサービスからの要求が「本物」であり、「許可されたもの」であることを確認する仕組みは非常に重要になる。この認証と認可のプロセスでよく使われるのがJSON Web Token (JWT) だが、多くのエンジニアがその検証方法について誤解していることがある。単に「サーバーが見つかった」とか「トークンに署名がある」というだけで、そのトークンが完全に安全だと信じてしまうのは危険な行為であり、これが不正アクセスやシステム乗っ取りにつながる可能性がある。

JWTは、情報をエンコードし、秘密鍵でデジタル署名されたデータのかたまりである。この署名によって、情報が改ざんされていないこと、そして発行元が正当であることを確認できる。しかし、署名が正しいからといって、そのトークンが「今、このサービスで使われるべきもの」であるとは限らない。なぜなら、JWTには「クレーム」と呼ばれるさまざまな情報が含まれており、その中に「誰がこのトークンを発行したか（発行者、iss）」「誰のためにこのトークンが発行されたか（対象者、aud）」といった重要な情報があるからだ。これらのクレームを正しく検証しないと、たとえ署名が有効であっても、不正な目的で利用される危険性がある。

多くのエンジニアが陥りがちなのが、設定情報の取得と実際のトークン検証を混同してしまうことだ。ITの世界では、サービス間の連携を容易にするために、認証サーバーやリソースサーバーが自身の情報（エンドポイントのURLや公開鍵の場所など）を「メタデータ」として公開する仕組みがある。RFC 8414は認証サーバーがエンドポイントやサポートする機能、公開鍵の場所をクライアントに知らせるためのメタデータ定義を、RFC 9728は保護されたリソースが、どの認証サーバーを使うべきか、どの種類のトークンをサポートするかを広告するためのメタデータ定義を定めている。これらは、クライアントが手動で設定を更新しなくても動的に情報を取得できるようにするための便利な仕組みだ。しかし、重要なのは、これらのメタデータはあくまで「設定情報」を提供するものであって、受信したトークンの正当性を「検証」するものではないという点だ。メタデータから公開鍵を取得したからといって、その鍵で署名されたトークン全てが無条件に信頼できるわけではない。

最もよくあるセキュリティ上の落とし穴の一つが、「有効な署名を持つが、誤った対象者向けに発行されたトークン」を受け入れてしまうケースだ。例えば、認証サーバーが「サービスA」のために発行したJWTがあったとする。このJWTには「対象者（aud）」として「サービスAのURL」が記述されている。もし攻撃者がこのトークンを不正に取得し、「サービスB」に提示した場合、サービスBが署名だけを検証し、「認証サーバーの公開鍵で署名されているから有効だ」と判断してしまうと、攻撃者はサービスBへのアクセス権を得てしまう可能性がある。これは、サービスAとサービスBが同じ認証サーバーを信頼している場合に起こりうる「マルチテナントトークンリプレイ攻撃」と呼ばれる。サービスBは、トークンの「対象者（aud）」クレームが自身のものではないことを確認し、そのトークンを拒否しなければならない。署名が正しいことは、そのトークンが「本物の認証サーバーから発行された」ことしか証明せず、「このサービスで使われるべきトークンである」ことまでは証明しないのだ。

このようなリスクを防ぐため、トークンを検証する際には「発行者（iss）」、「対象者（aud）」、「アルゴリズム（alg）」の三つのクレームを厳格にチェックする必要がある。発行者（iss）のチェックでは、トークンを発行したエンティティが、システムが信頼している発行者のリストに含まれているかを検証する。未知の、あるいは不正な認証サーバーからのトークンを受け入れてしまえば、システム全体が危険にさらされる。対象者（aud）のチェックでは、トークンが本当に現在アクセスしようとしているサービスのために発行されたものかを確認する。これは、異なるアプリケーション層のために発行されたトークンを誤って受け入れてしまうことを防ぎ、先述のリプレイ攻撃を防ぐ上で非常に重要だ。アルゴリズム（alg）のチェックでは、JWTのヘッダーに含まれる署名アルゴリズム情報が、システムが許可するアルゴリズムと一致するかを検証する。特に「none」というアルゴリズムは署名が一切ないことを意味するため、許可してはならない。また、システムが非対称鍵暗号（例: RS256）を期待しているにもかかわらず、対称鍵暗号（例: HS256）で署名されたトークンを受け入れてしまう「アルゴリズムの混同」も危険であり、許可するアルゴリズムはRS256のように厳しく指定するべきだ。

これらの問題を解決するためには、認証・認可の処理において、受信したJWTに対して厳格な「ランタイムチェック」を行うことが不可欠である。例えば、jsonwebtokenのようなライブラリを使ってJWTを検証する際には、署名を検証するだけでなく、検証関数のオプションとして発行者、対象者、許可するアルゴリズムを明示的に指定することが非常に重要になる。これにより、期待通りの条件を満たさないトークンは、たとえ署名が有効であっても拒否されるようになる。公開鍵の取得はメタデータディスカバリから行いつつも、信頼の判断はランタイムのクレーム検証に委ねる、という考え方が重要だ。さらに、アクセストークンが必要な場面で、IDトークンやその他のアサーション（主張）を受け入れてしまうような「トークンタイプの混同」もセキュリティ上の問題となるため、それぞれのトークンタイプが持つ役割と権限を理解し、プロトコルに応じた適切なトークンタイプを厳格に要求する必要がある。

システムエンジニアを目指す上で、このような認証・認可のセキュリティ原則を理解し、実装することは非常に重要だ。単にライブラリやフレームワークが提供する機能を使うだけでなく、その内部で何がどのように検証されているのかを深く理解し、常に「このトークンは本当に信頼できるか？」「このサービスで受け入れるべきか？」という視点を持つことが求められる。メタデータは設定の発見に使い、実際のセキュリティ検証は発行者、対象者、アルゴリズムといったクレームの厳格なチェックに頼る。これにより、予期せぬなりすましや不正アクセスを防ぎ、より堅牢で安全なシステムを構築できるだろう。