ID トークンとアクセス トークン: OpenID Connect における決定的な違い

By Mirko Peters · 2026-10-28

OpenID Connect における ID トークンとアクセス トークンの重要な違いを解説し、両者を混同するとなぜ深刻なセキュリティ上の欠陥につながるのかを説明します。

Automatically translated with AI from the original post. Read the English original

ID トークンとアクセス トークンの違いを理解することは、最新の認証を扱う開発者や IT 管理者にとって極めて重要です。OAuth 2.0 はアクセス許可を扱い、OpenID Connect は ID トークンを導入してユーザーの ID を確認します。この二つの異なるトークンを混同すると、クラウド アプリケーションに重大なセキュリティ上の脆弱性が生じます。

重要なポイント

• ID トークンはユーザーの ID を証明し、アクセス トークンは認可とアクセス許可を付与します。
• この二つのトークンを混同することは、自社開発アプリケーションのセキュリティにおける代表的な誤りです。
• OpenID Connect は、OAuth 2.0 の枠組みの上に ID の確認機能を重ねたものです。
• アクセス トークンは取り消すことができるため、パスワードを保存するよりも安全な状態を保てます。
• アプリは受け取った ID トークンを無条件に信頼するのではなく、暗号的に検証する必要があります。

中核となるジレンマ: ID と認可の違い

最新の Web アプリケーションの進化の中で、開発者はユーザーのサインインの仕組みと、ユーザーが基盤となるデータとどのようにやり取りするかについて、混乱に直面することがしばしばあります。この混乱の多くは、ID の分野で用語が重複していることに起因します。アプリケーションが Web 上で急速に拡大し始めた当初、ユーザー名とパスワードの組み合わせだけに頼ることは、大きなセキュリティ上のボトルネックとなりました。ユーザーは数十の異なる資格情報を管理することに疲弊し、複数のプラットフォームで弱いパスワードを使い回すようになりました。

この問題の一部を解決するために登場したのが OAuth 2.0 です。しかし OAuth 2.0 は、そもそも「その人が誰であるか」に答えるために作られたものではありません。その目的は、ユーザーに代わって特定のデータ エンドポイントにアクセスすることをアプリケーションに許可する、アクセス トークンという「許可証」を提供することです。アクセス トークンはアプリケーションが何をできるかを示しますが、そのトークンを持つ人物が誰であるかについては、まったく何も示しません。この根本的な隔たりがあったため、シングル サインオンを実現しようとする企業は、独自の ID チェックを OAuth に後付けするしかありませんでした。その結果、互いに整合しない断片的な実装が生まれることも少なくありませんでした。

OpenID Connect は、まさにこの隔たりを埋めるために、認証専用に設計された標準化されたレイヤーを導入しました。従来のアクセス トークンと並んで二つ目のトークンを用いることで、OpenID Connect は ID の問題とアクセス許可の問題を明確に分離します。今日、クラウド アプリケーションを構築または監査するすべての人にとって、この二つの概念を切り分けて考えることは、最も重要な考え方の転換です。

ID トークンの構造: 中身を見る

ユーザーが「Microsoft でサインイン」ボタンをクリックすると、ID プロバイダーは資格情報を処理し、多要素認証の要件に対応したうえで、最終的に ID トークンを添えてユーザーをアプリケーションに戻します。このトークンは JSON Web Token、通称 JWT (「ジョット」と発音) としてパッケージ化されています。一見すると JWT は、ドットで区切られた、近寄りがたく解読不能な文字列に見えます。しかし、デコードしてみると、その内部構造は驚くほど単純です。

ID トークンの中には、それぞれ明確な目的を持つ標準的なクレームがいくつか含まれています。

• 発行者 (Issuer): トークンを生成して署名した ID プロバイダー (Microsoft Entra ID など) を示します。
• Subject (sub): ユーザーを一意に識別する、変更不可の識別子です。重要な点として、ユーザーが表示名やメールアドレスを更新しても変わらないように設計されています。
• Audience (aud): トークンが発行された対象アプリケーションを指定します。これにより、あるアプリ向けのトークンを、別のアプリが悪意を持って傍受して再利用することを防ぎます。
• Timestamps: トークンの発行日時、有効期限、およびユーザーが認証を完了した正確な時刻を示します。
• Nonce: 発行されたトークンを、その要求を開始したサインインセッションに結び付ける、安全な受付番号の役割を果たします。これにより、リプレイ攻撃を効果的に防ぎます。

重要なのは、パッケージ全体がプロバイダーの秘密キーで署名されている点です。受信側のアプリケーションは、プロバイダーが公開している対応する公開キーを使って、この署名を検証します。この暗号学的な検証がなければ、ID トークンは当事者間でやり取りされる、検証されていないメモに過ぎません。

アイデンティティをアクセス権として扱う危険性

アプリケーション開発で最も危険なアンチパターンの一つが、ID トークンをアクセス権の鍵として扱うことです。ID トークンは、ユーザーが特定の組織に所属する John Doe であることを確認するものなので、経験の浅い開発者が、その確認をもとに管理権限や無制限のデータベースアクセスを与えてしまうことがあります。これはアーキテクチャを根本的に誤解しています。

ID トークンが示すのは、玄関に立っているのが誰かということだけです。その人物がすべての部屋に入ってよいのか、特定の管理ボタンを押してよいのかについては、何も示しません。認可のロジックは、アプリケーションがロールベースのアクセス制御などの仕組みを使って別途処理する必要があります。検証済みのアイデンティティは、最終的な認可の決定ではなく、あくまで出発点として扱うべきです。

さらに、アプリケーションが適切な検証を行わずに、受信した ID トークンを受け入れてしまうという誤りがよく見られます。ライブラリが裏側で処理したというだけで、トークンを無条件に信頼すると、偽造されたデータにシステムがさらされます。署名の検証、有効期限の確認、オーディエンス・クレームの検証は、安全な状態を保つうえで欠かせない手順です。

結論

アイデンティティと認可の境界を理解すると、現代のクラウドアーキテクチャが分かりやすくなります。ID トークンは「キーボードの前にいるのは誰か」を証明することだけに限定し、アクセストークンに「どの操作が許可されるか」を管理させることで、開発者は Microsoft Entra ID のようなプラットフォームと連携する、堅牢で安全なインテグレーションを構築できます。これらの概念を総合的に解説し、Microsoft のエコシステムで最新のサインインワークフローがどのように動作するかを知りたい方は、ぜひ完全版のディスカッションをご覧ください。エピソード全体を聴くと、クラウド アイデンティティの仕組みについて、さらに理解を深められます。

よくある質問

ID トークンを使って API を呼び出したり、保護されたリソースにアクセスしたりできますか。

いいえ。ID トークンに含まれるのは、ユーザーが誰であるかを示すアイデンティティのクレームだけです。API を呼び出したり、保護されたリソースにアクセスしたりするには、アプリケーションが OAuth 2.0 で発行されたアクセストークンを使用する必要があります。

OpenID Connect と OAuth 2.0 が別々のトークンを使用するのはなぜですか。

アイデンティティと認可を分離することで、アプリケーションは、ログインしているユーザーが誰かを検証できます。その一方で、ユーザーの基になるデータやリソースを自由に操作する無制限の権限を、そのアプリケーションに与える必要はありません。

署名を検証せずに ID トークンを受け入れると、どうなりますか。

署名の検証を省略すると、アプリケーションは偽造トークンに対して脆弱になります。有効なユーザーだと主張する独自の文字列を、誰でも作成できてしまうためです。

nonce の値は、トークン交換のどの段階で使われますか。

nonce は、サインインフローの開始時に生成されるランダムな文字列で、ID トークンの中に埋め込まれます。これにより、アプリケーションはリプレイ攻撃を防げます。