JWTを解剖してアクセストークン・IDトークンを実物で理解してみる ― 手を動かして学ぶOAuth2.0/OIDC

こんにちは！DXソリューション営業本部の大和矢です。

OAuth2.0とOpenID Connect（OIDC）——情報処理安全確保支援士の試験でも頻出のテーマですね。
「アクセストークン」「IDトークン」「認可コードフロー」「PKCE」…用語は一通り追えるのに、いざ説明しようとするといまひとつ腹落ちしていない、という経験はありませんか？

筆者もそうです。ということで、今回は筆者のお勉強にお付き合いください。
具体的には、自分のEntraアプリで認可コード＋PKCEフローを実際に踏み、発行されたJWT（JSON Web Token）を解剖して仕様と突き合わせる、という手を動かすアプローチを取ります。
トークンの"実物"を一度見ておくと、解像度が変わります。

OAuth2.0とOIDCの役割分担

まず押さえるべきは、OAuthは「認可」、OIDCは「認証」という役割分担です。
Microsoftの公式ドキュメントも「このプラットフォームでは、OAuthが承認（認可）に使用され、OpenID Connect（OIDC）が認証に使用されます」と明記しています（認証と認可）。

認証（Authentication）は「あなたは誰か（本人か）」を確かめること、認可（Authorization）は「何をしてよいか（権限）」を与えることです。
OIDCはOAuth2.0の上に構築されているため、用語やフローがよく似ていて混同しがちですが、この2つは目的が違います。

この違いが、そのまま2種類のトークンに対応します。

公式ドキュメントは「API を呼び出すために ID トークンを使用しないでください」とはっきり書いています（ID トークン）。
IDトークンは"本人確認の証明書"、アクセストークンは"入館証"、と役割が分かれている点をまず押さえてください。

認可コード＋PKCEフローを実際に踏む

では実際にトークンを取得してみます。
使うのは、現在もっとも標準的な認可コードフロー＋PKCE（Proof Key for Code Exchange）です。

PKCEは、認可コードの"横取り"を防ぐための拡張です。
クライアントはまず、ランダムな秘密（code_verifier）を生成し、そのハッシュ（code_challenge）だけを認可リクエストに載せて送ります。
そして認可コードをトークンに交換する段階で、元の code_verifier を一緒に送り、認可サーバーが「先に受け取った code_challenge と対応するか」を検証します。
この仕組みにより、たとえ通信経路や別アプリ経由で認可コードを盗まれても、code_verifier を知らない攻撃者はトークンに交換できません（この code_verifier / code_challenge は、後述のリクエスト例にそのまま登場します）。

PKCEは、Microsoft IDプラットフォームではSPA（Single-Page Application＝ページ遷移せず1枚の画面をJavaScriptで書き換えるブラウザ内アプリ。React／Angular／Vueなど）で必須、ネイティブアプリや機密クライアント（Webサーバー側で秘密を安全に保持できるアプリ）で推奨です（2026年7月時点、サード パーティ Cookie のブロック）。

全体像は次のとおりです。クライアント（自分のアプリ）・Microsoft Entra ID・Microsoft Graphの3者が、①〜⑥の順にトークンをやり取りします。
以降の手順は、この図の①〜⑥を実際に踏んでいく流れです。

準備として、Azure（Microsoft Entra管理センター）でアプリを登録します。

フローの流れはシンプルです。
まず認可エンドポイントに code_challenge を付けてアクセスし、サインイン・同意の後に短命の認可コードを受け取ります。
リダイレクトURIには http://localhost を使います（システムブラウザを使うクライアントでの推奨値）。
認可後、認可コードは http://localhost/?code=... の形でブラウザのアドレスバーに返るので、そこから code を取り出します（ページ自体は「アクセスできません」と表示されますが、URLの code が拾えれば問題ありません）。

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
  ?client_id={clientId}
  &response_type=code
  &redirect_uri=http://localhost
  &scope=openid profile offline_access User.Read
  &code_challenge={code_challenge}
  &code_challenge_method=S256
  &state={ランダム値}

• client_id：
  ステップ1で登録したアプリの識別子。
• response_type=code：
  認可コードフローを使うことを示す固定値。
• redirect_uri：
  認可後にコードを受け取るURL。登録したリダイレクトURIと完全に一致させる必要がある。
• scope：
  要求する権限。openid＝IDトークンの発行、profile＝氏名等の追加クレーム、offline_access＝リフレッシュトークン、User.Read＝Microsoft Graphでの自分のプロフィール読み取り。
• code_challenge / code_challenge_method：
  PKCEのハッシュ値と、その生成方式（S256）。上で説明したとおり、code_verifier をハッシュ化して作る値。
• state：
  CSRF対策のランダム値。リダイレクト後、送信時と同じ値が返ってきたかを確認する。

次に、受け取った認可コードを、code_verifier（code_challengeの元になった秘密）と一緒にトークンエンドポイントへ送り、トークンに交換します。
このステップは POST なので、ブラウザだけでは踏めません。
今回は追加アプリを入れず、Windows標準の PowerShell（Invoke-RestMethod）から実行します。

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id={clientId}
&code={認可コード}
&code_verifier={code_verifier}
&redirect_uri=http://localhost

• grant_type=authorization_code：
  認可コードをトークンに交換する要求であることを示す固定値。
• client_id：
  認可リクエストと同じアプリの識別子。
• code：
  認可エンドポイントから受け取った認可コード。
• code_verifier：
  code_challengeの元になった秘密の値。ここで初めて明かすことで、認可コードを盗んだだけの第三者にはトークンへ交換できないようにする。
• redirect_uri：
  認可リクエストで使ったものと完全に一致させる必要がある。

成功すると、access_token（アクセストークン）、id_token（openidスコープ要求時）、refresh_token（offline_access要求時）が返ってきます。

なお、こうして生のHTTP要求を手で組み立てるのは仕組みを理解するための学習用です。
実運用のアプリでは、公式も「生の HTTP 要求を手動で作成して発行することはお勧めしない。代わりにMSAL（Microsoft Authentication Library）などのサポートされたライブラリを使う」と案内しています（認可コードフロー）。

実際に認可コード＋PKCEフローを踏んだところ、access_token・id_token・refresh_tokenの3つがすべて返ってきました。
仕様どおりに動くことを、自分の手元で確認できたことになります。

JWTを解剖する（jwt.msでデコード）

取得したIDトークンを解剖してみましょう。
Microsoftは、検証・デバッグ用のデコードサイトとして jwt.ms を案内しています。
ただし公式は、これを「検証とデバッグのみを目的として」使うものと釘を刺しており、本番のアプリロジックに組み込む用途ではありません（アクセストークン）。

JWTはヘッダー・ペイロード（クレーム）・署名の3要素が、ピリオド（.）で区切られ、それぞれBase64でエンコードされた構造です。
jwt.msに貼ると、この3要素が読める形で展開されます。

主なクレーム（トークンに含まれる情報）を、支援士の設問で問われる観点と対応させると次のようになります。

落とし穴：検証していいトークン、してはいけないトークン

ここが本記事で一番伝えたいポイントです。
アクセストークンは、受け取ったクライアントが検証してはいけません。
「トークンなんだから中身を検証するのが安全では？」と思いがちですが、これは誤解です。

Microsoftの公式ドキュメント（アクセストークン）は、次のように明記しています。

（日本語・公式）
「クライアント アプリケーションはアクセス トークンを受け取って使用できますが、それらを不透明な文字列として扱う必要があります。クライアント アプリケーションは、アクセス トークンの検証を試みることはできません。リソース サーバーは、アクセス トークンを認可の証明として受け入れる前に検証する必要があります。」

（英語・原文）
"Although client applications can receive and use access tokens, they should treat them as opaque strings. The client application shouldn't attempt to validate access tokens. The resource server should validate the access token before accepting it as proof of authorization."

つまり、Microsoft Graphなど他のリソース宛に発行されたアクセストークンは、あなたのアプリにとっては中身を覗く対象ではなく、そのまま渡す"切符"です。
検証するのは、それを受け取るリソースサーバー（API側）の責務です。

一方で、自分が受け取るIDトークンは検証するのが正解です。
IDトークンは「あなた（クライアント）宛」に発行された本人確認の証明なので、署名・発行者（iss）・対象者（aud）・有効期限（exp）などを検証します。
この「アクセストークンは検証しない／IDトークンは検証する」という非対称性が、トークンを扱ううえでの最重要ポイントです。

リソース側がトークンを検証するときの観点

参考までに、API（リソースサーバー）側が受け取ったトークンを検証する場合の観点も挙げておきます。

• 署名：
  ヘッダーの alg（例 RS256）と kid（鍵の識別子）を使い、OIDCメタデータの jwks_uri から取得した公開鍵で検証する。
• aud の一致：
  自分（API）を宛先とするトークンだけを受け入れる。宛先違いを受け入れると「confused deputy（混乱した代理人）」問題になる。
• iss の完全一致・有効期限：
  発行者を厳密に照合し、exp/nbf/iat の時刻を確認する。
• 鍵のローテーション：
  Microsoft Entra IDは署名鍵をいつでもロールオーバーする可能性があり、ロール間隔は保証されない。公式は、公開鍵のキャッシュ有効期限を24時間とし、更新チェックは1時間ごとに行うことを推奨している（署名キーのロールオーバー）。

よくある質問

まとめ：トークンは"切符"、実物で仕様を確かめる

今回は、認可コード＋PKCEフローを実際に踏み、発行されたJWTをjwt.msで解剖しました。
学びは次の3つです。

• OAuthは認可・OIDCは認証：
  アクセストークン（入館証）とIDトークン（本人確認証）は役割が違う。IDトークンでAPIを呼ばない。
• アクセストークンはクライアントが検証しない：
  他リソース宛のアクセストークンは不透明な文字列。中身に依存せず、検証はリソース側の責務。
• IDトークンは自分で検証する：
  署名・iss・aud・expを検証する。この非対称性が設計判断の分かれ目。

トークンは、中身を詮索する対象ではなく、役割の決まった"切符"です。
用語だけで覚えていたOAuth/OIDCも、実物のJWTを一度解剖すると、設計判断のときに迷いが減ります。
ブラウザとPowerShell、jwt.msだけで試せるので、まずは自分のIDトークンを1枚、解剖してみてはいかがでしょうか。

ここまでお読みいただき、ありがとうございました。
本記事で扱った「トークンの検証」や「アクセストークンの宛先（audience）」を、Azure API Management・MCPで実際に実装した例として、次の記事もあわせてご覧いただけますと幸いです。

MCPサーバーをAPI Managementで守る - 従量課金プランで低コスト＆セキュアな認証ゲートウェイ | QES ブログ
Azure API Management（従量課金）でMCPサーバーを保護し、Entra IDのJWTを署名・発行者・audience・有効期限で検証する認証ゲートウェイの実装。本記事の「リソース側がトークンを検証する観点」を実際に構築した例です。
 

API Management×Graph API - OBOフローでMCPのユーザー情報を拡張してみた | QES ブログ
OBO（On-Behalf-Of）フローで、MCPサーバー宛のアクセストークンをMicrosoft Graph用トークンに交換し、ユーザー情報を取得する実装。本記事の「アクセストークンは宛先（audience）ごとに発行される」を実践した例です。
 

※このブログで参照されている、Microsoft、Azure、Microsoft Entra ID、Microsoft Graphは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。