【OAuth 2.0 / PKCE 認可コードグラントの全シーケンス解説】～情報処理安全確保支援士試験 令和5年春期 午後Ⅱ 問2より～

2026年現在、安全確保支援士試験に鋭意チャレンジ中です。
どうしてもOAuth2.0認可コードグラントが覚えられなくて整理のために記事にしました。

情報処理安全確保支援士 令和5年春期 午後Ⅱ 問2を題材に、OAuth 2.0認可コードグラントとPKCE（RFC 7636）の連携シーケンス全10ステップをHTTP電文例とともに詳しく解説します。

安全確保支援士試験や高度試験にチャレンジしている同志の方の参考になればと～

① 認可フェーズ

「認可フェーズ」は利用者の同意確認を行います。

１．サービス要求 （[スマホアプリ]→[Webサーバ]）

アプリがWebサーバへ「記事を投稿し、サービスTへも送信してほしい」と HTTP POST を送ります。

実際の投稿では、日記の本文データに加え、「サービスTにも連携投稿したい」という指示（フラグ）がデータ部（JSONなど）に含まれます。（推測）

POST /api/v1/diaries HTTP/1.1
Host: diary.example.com
Authorization: Bearer <これがのちに盗まれる新日記サービス自体のログインセッショントークン>
Content-Type: application/json

{
  "title": "本日の活動記録",
  "content": "本日はセキュリティ試験の勉強を行いました。",
  "share_to_service_t": true
}

• パラメータ：
  • title：日記のタイトル
  • content：日記の本文
  • share_to_service_t：サービスTへの同時投稿フラグ（true）
• 送信内容：日記の本文データに加え、「サービスTにも連携投稿したい」という指示（フラグ）がデータ部（JSONなど）に含まれます。（推測）

２．リダイレクト（ [Webサーバ] → [スマホアプリ]）

新日記サービスのWebサーバは記事データを受信しますが、サービスTへ代理投稿するためのアクセストークンをまだ所持していません。そのため、会員に対してサービスTの認可画面へアクセスするよう指示を返します。

HTTP/1.1 302 Found
Location: https://service-t.example.com/oauth/authorize?response_type=code&client_id=abcd1234&redirect_uri=diaryapp%3A%2F%2Fcallback

• パラメータ（Locationヘッダ内）：
  • response_type=code：認可コードグラント方式の指定
  • client_id=abcd1234：サービスTから新日記サービスへ事前発行された識別子
  • redirect_uri=diaryapp://callback：認可完了時に戻る先となるカスタムURLスキーム
• 処理内容：HTTPレスポンスヘッダの Location にサービスTの認可エンドポイントURLを指定し、ステータスコード 302 Found を返します。

３．認可要求 （[スマホアプリ] →[認可サーバ]）

スマホアプリはアプリ内ブラウザ等を開き、サービスTの認可サーバへ認可要求を送信します（設問3(2) 表8のリクエスト[ p ]に該当）。

GET /oauth/authorize?response_type=code&client_id=abcd1234&redirect_uri=diaryapp%3A%2F%2Fcallback&code_challenge=E9Melhoa2OwvFrGMTJguCH5rtx64LxU4b...&code_challenge_method=S256 HTTP/1.1
Host: service-t.example.com

• 送信パラメータ：
  • response_type=code：認可コードグラントの指定
  • client_id：事前発行された識別子
  • redirect_uri：認可後に戻るカスタムURLスキーム（例: diaryapp://callback）
  • code_challenge：先ほど生成したハッシュ値（チャレンジコード）
  • code_challenge_method=S256：変換方式（SHA-256）の明示
  • ※state：CSRF（クロスサイトリクエストフォージェリ）防止用の推測困難なランダム文字列（※本試験設問では省略されていますが、RFC 6749 Section 10.12にて推奨されているパラメータです）
• 認可サーバ側の動作：受け取ったチャレンジコードを一時保存します。

４．認可同意処理 （[スマホアプリ] → [認可サーバ]）

サービスTの認可サーバが画面を提示し、会員本人がアクセス権の付与を確認します。
（以下はGemini生成のダミーです）

• 処理内容：会員がサービスTにログインしていない場合はログイン認証を行い、認可画面で「許可する」を選択します。

② 引き換えフェーズ

「引き換えフェーズ」では、同意に基づき発行された一時的な認可コード（引き換え券）を回収し、安全にバックエンドへ引き渡します。

５．リダイレクト（ [認可サーバ] → [スマホアプリ]）

認可サーバは同意を確認すると、一時的な「認可コード（code）」を払い出し、指定された redirect_uri（カスタムURLスキーム）へリダイレクトします。

HTTP/1.1 302 Found
Location: diaryapp://callback?code=5810f68ad195469d85f59a6d06e51e90

• パラメータ（Locationヘッダ内）：
  • code=5810f68ad195469d85f59a6d06e51e90：認可サーバが発行した一時的な認可コード本体
• セキュリティ上の着眼点：端末内に悪意のある別アプリが存在する場合、このリダイレクトを横取りされるリスクがあります。しかし、攻撃者は手元に正規アプリのメモリ内にある検証コード（code_verifier）を持たないため、コード単体を奪われても悪用できません。

６．認可コードの受け渡し （[スマホアプリ] → [Webサーバ]）

スマホアプリは、認可サーバから受け取った「認可コード」と、手元に保持していた「検証コード」をセットにして、新日記サービスのWebサーバへ送信します。

POST /api/v1/oauth/callback HTTP/1.1
Host: diary.example.com
Authorization: Bearer <これがのちに盗まれる新日記サービス自体のログインセッショントークン>
Content-Type: application/json

{
  "code": "5810f68ad195469d85f59a6d06e51e90",
  "code_verifier": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}

• パラメータ：
  • code：認可サーバから受け取った認可コード
  • code_verifier：スマホアプリのメモリに保持していた検証コード原本
• 処理内容：端末側のスマホアプリからバックエンドのWebサーバへ、認可コードと検証コードの原本を引き渡します。

③ 発行・実行フェーズ

「発行・実行フェーズ」では、サーバ間の直接通信（バックチャネル）により、安全にアクセストークンを取得して代理処理を実行します。

７．アクセストークン要求（ [Webサーバ] → [認可サーバ]）

新日記サービスのWebサーバ（コンフィデンシャルクライアント）は、サービスTの認可サーバへ直接接続し、アクセストークンを要求します（設問3(2) 表8のリクエスト[ q ]に該当）。

POST /oauth/token HTTP/1.1
Host: service-t.example.com
Authorization: Basic YWJjZDEyMzQ6UEBzc3dvcmQ=
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=5810f68ad195469d85f59a6d06e51e90&redirect_uri=diaryapp%3A%2F%2Fcallback&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

• パラメータ：
  • Authorization: Basic ...：新日記サービス自体のクライアント認証ヘッダ（IDとシークレット）
  • grant_type=authorization_code：認可コードグラントによるトークン要求の指定
  • code：提示する認可コード（ステップ5・6）
  • redirect_uri：認可要求時と同一のコールバックURI
  • code_verifier：スマホアプリから預かった検証コード原本（ステップ6）
• 処理内容：新日記サービスのWebサーバ（コンフィデンシャルクライアント）が認可サーバへ直接接続し、アクセストークンを要求します（表8のリクエスト番号 [ q ]）。

８．アクセストークン応答 （[認可サーバ] → [Webサーバ]）

検証に成功した認可サーバは、新日記サービスのWebサーバ宛てにアクセストークンを発行します。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "write:posts"
}

• パラメータ：
  • access_token：発行されたアクセストークン
  • token_type：トークン形式（Bearerトークン）
  • expires_in：トークンの有効秒数（3600秒）
  • scope：認可された操作範囲（write:posts）
• 処理内容：Webサーバは発行されたアクセストークンをデータベース等のセキュアな領域に保管します。

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_grant",
  "error_description": "PKCE verification failed or invalid authorization code."
}

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_client",
  "error_description": "Client authentication failed."
}

９．記事投稿 （[Webサーバ] → [リソースサーバ]）

新日記サービスのWebサーバは、取得したアクセストークンをヘッダに付与し、サービスTのリソースサーバ（投稿API）へ記事を代理投稿します。

POST /api/v1/posts HTTP/1.1
Host: api.service-t.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
Content-Type: application/json

{
  "status": "【新日記サービスより同時投稿】本日の活動記録：本日はセキュリティ試験の勉強を行いました。"
}

• パラメータ：
  • Authorization: Bearer ...：ステップ8で取得したアクセストークン
  • status：サービスT（SNS）へ投稿する本文データ
• 処理内容：Webサーバは取得したアクセストークンをヘッダに付与し、サービスTのリソースサーバ（投稿API）へ記事を代理投稿します。リソースサーバは添付されたアクセストークンの署名や有効期限を検証し、正当であれば投稿処理を実行します。

１０．記事投稿結果取得 （[リソースサーバ]→ [Webサーバ]）

サービスTのリソースサーバからWebサーバへ投稿完了の通知が返されます。

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "post-987654",
  "created_at": "2026-09-23T16:00:00Z"
}

• パラメータ：
  • id：投稿された記事の固有識別子
  • created_at：投稿作成日時
• 処理内容：新日記サービスのWebサーバは投稿完了を確認し、ステップ1で保留されていたスマホアプリへの応答（日記保存およびSNS連携完了通知）を返して全シーケンスが終了します。（以下はGemini生成のダミー通知です）