CIBAとは何か
このドキュメントの目的
CIBA（Client Initiated Backchannel Authentication） の基礎を理解し、従来のOAuth 2.0フローとの違いを把握することが目標です。
従来のフロー vs CIBA
従来のAuthorization Code Flow
特徴: 認証要求と認証実行が同じデバイス
┌─────────────────────────────────────────────────┐
│ │
│ [Webブラウザ] │
│ │
│ 1. ログインボタンをクリック │
│ ↓ │
│ 2. 認可サーバーにリダイレクト │
│ ↓ │
│ 3. ログイン画面でパスワード入力 ←─────────┐ │
│ ↓ 同じ │
│ 4. 認証完了 デバイス│
│ ↓ │ │
│ 5. Authorization Code取得 │ │
│ ↓ │ │
│ 6. Token Request │ │
│ ↓ ─────┘ │
│ 7. Access Token取得 │
│ │
└─────────────────────────────────────────────────┘
制約:
- ユーザーはブラウザでパスワードを入力する必要がある
- キーボードがないデバイス（ATM、TV）では入力が困難
CIBA
特徴: 認証要求と認証実行が異なるデバイス
┌──────────────────┐ ┌──────────────────┐
│ │ │ │
│ [PCアプリ] │ │ [スマホアプリ] │
│ │ │ │
│ 1. ログイン要求 │ │ │
│ ↓ │ │ │
│ 2. 認証リクエスト│ │ │
│ ↓ │ │ │
│ ┌──────────────┐ │ │ │
│ │認可サーバー │ │──3. プッシュ通知──→│ 4. 通知受信 │
│ │ │ │ │ ↓ │
│ │ auth_req_id │ │ │ 5. 内容確認 │
│ │ 返却 │ │ │ ↓ │
│ └──── ──────────┘ │ │ 6. 生体認証 │
│ ↓ │ │ ↓ │
│ 7. ポーリング │ │ 7. 承認/拒否 │
│ （5秒ごと） │ │ ↓ │
│ ↓ │ │ ┌──────────────┐ │
│ ┌──────────────┐ │ │ │認可サーバー │ │
│ │認可サーバー │ │←──8. 承認完了記録──│ │ │ │
│ │ │ │ │ └──────────────┘ │
│ │ Token発行 │ │ │ │
│ └──────────────┘ │ │ │
│ ↓ │ │ │
│ 9. Access Token │ │ │
│ 取得 │ │ │
│ │ │ │
└──────────────────┘ └──────────────────┘
認証要求デバイス 認証実行デバイス
利点:
- PCにパスワード入力不要
- スマホの生体認証を活用
- デバイス分離によるセキュリティ向上
なぜCIBAが必要か
理由1: デバイス分離
PCで操作 ← ユーザー
↓
スマホで認証 ← 安全なデバイス
メリット:
- PCがマルウェアに感染していても、スマホで認証を制御
- PCにパスワード入力不要（キーロガーリスク回避）
理由2: 入力デバイスがない
ATM、キオスク端末、スマートTV、IoTデバイス
↓ キーボードがない、または入力が困難
↓
スマホで認証すれば解決
理由3: ユーザー体験向上
従来:
パスワード入力 → SMS受信 → コード入力 → ログイン完了
（3ステップ、面倒）
CIBA:
スマホに通知 → タップして生体認証 → ログイン完了
（1ステップ、簡単）
CIBAの基本フロー
ステップ1: 認証リクエスト
クライアント → 認可サーバー
パラメータ:
- login_hint: ユーザー識別子（電話番号、email等）
- binding_message: ユーザーに表示するメッセージ（例: "100万円送金"）
ステップ2: 認可サーバーがauth_req_id返却
認可サーバー → クライアント
レスポンス:
- auth_req_id: 認証リクエストの識別子
- expires_in: 有効期限（例: 300秒）
- interval: ポーリング間隔（例: 5秒）
ステップ3: プッシュ通知
認可サーバー → ユーザーのスマホ
通知内容:
"ログインリクエスト
メッセージ: 100万円送金
[承認] [拒否]"
ステップ4: ユーザーが承認
ユーザーのスマホ → 認可サーバー
- 生体認証（指紋、顔認証）
- 承認ボタンをタップ
ステップ5: クライアントがトークン取得（ポーリング）
クライアント → 認可サーバー（5秒ごとにポーリング）
パラメータ:
- grant_type: urn:openid:params:grant-type:ciba
- auth_req_id: ステップ2で取得したID
レスポンス（承認待ち）:
- error: authorization_pending
レスポンス（承認完了）:
- access_token
- id_token
- refresh_token
CIBAの3つのモード
Poll Mode（ポーリング）
クライアントが定期的に問い合わせ
クライアント ─5秒ごと─→ 認可サーバー
←まだ待機─
─5秒ごと─→
←まだ待機─
─5秒ごと─→
←Token発行─
特徴: 最も一般的、ファイアウォール越えが容易
Ping Mode（通知）
承認完了時にクライアントに通知
クライアント ←─通知─── 認可サーバー
─Token要求→
←Token発行─
特徴: 効率的、Inbound HTTP必要
Push Mode（直接配信）
承認完了時にトークンを直接Push
クライアント ←─Token直接Push─ 認可サーバー
特徴: 最も効率的、セキュリティリスク高
推奨: Poll Mode
セキュリティ考慮事項
binding_messageの重要性
目的: ユーザーが何を承認しているか明確にする
❌ 悪い例:
"ログインしますか？" ← 何のログインか不明
✅ 良い例:
"100万円の送金を承認しますか？
送金先: ○○銀行 △△支店
Code: 1234" ← 具体的
効果: フィッシング対策
有効期限
推奨: 短い有効期限（300秒 = 5分）
理由: 長すぎると攻撃者が承認を待つ時間が増える
まとめ
従来のフロー vs CIBA
| 項目 | 従来のフロー | CIBA |
|---|---|---|
| 認証デバイス | 同じ | 異なる |
| ユーザー操作 | ブラウザでパスワード入力 | スマホで生体認証 |
| 通信 | フロントチャネル（リダイレクト） | バックチャネル（直接通信） |
| 適用シーン | 一般的なWebアプリ | ATM、IoT、高額取引 |
学んだこと
- ✅ CIBAは認証要求デバイスと認証実行デバイスが異なる
- ✅ バックチャネル（直接通信）で認証
- ✅ 3つのモード（Poll推奨）
- ✅ なぜCIBAが必要か（デバイス分離、セキュリティ、UX）
- ✅ binding_messageの重要性
次に読むべきドキュメント
- CIBAのユースケース - 実際の活用例
- CIBA Flow実装ガイド - 実装方法
最終更新: 2025-12-18 対象: IDサービス開発初心者