CIBAのユースケース
このドキュメントの目的
CIBAが実際にどのような場面で活用されるかを理解し、適用シーンを把握することが目標です。
ユースケース1: ATM認証
シナリオ
[ATM端末] ← ユーザーが操作
↓ 認証リクエスト
[認可サーバー]
↓ プッシュ通知
[ユーザーのスマホ]
"ATMで出金リクエスト: 10,000円
承認しますか？"
↓ 生体認証で承認
[認可サーバー]
↓ Token発行（ポーリング）
[ATM端末]
→ 出金処理実行
メリット
- セキュリティ: ATMにパスワード入力不要（盗撮リスクなし）
- UX: スマホの生体認証で簡単・安全
- デバイス分離: ATMが信頼できなくても、スマホで認証を制御
ユースケース2: コールセンター認証
シナリオ
[顧客] 電話でコールセンターに問い合わせ
↓
[オペレーター] システムで顧客情報にアクセス必要
↓ 認証リクエスト（ユーザー識別子: 顧客の電話番号）
[認可サーバー]
↓ SMS/プッシュ通知
[顧客のスマホ]
"オペレーターがあなたの情報にアクセスしようとしています
承認しますか？"
↓ 承認
[認可サーバー]
↓ Token発行
[オペレーターのシステム]
→ 顧客情報にアクセス
メリット
- 本人確認: 電話の相手が本当に顧客本人か確認
- セキュリティ: なりすまし防止
- 監査: 顧客の明示的な承認を記録
ユースケース3: IoTデバイス認証
シナリオ
[スマートTV] ← ユーザーが動画配信サービスにログイン
"スマホで承認してください"
↓ 認証リクエスト
[認可サーバー]
↓ プッシュ通知
[ユーザーのスマホアプリ]
"スマートTVでログインしようとしています
承認しますか？"
↓ 生体認証で承認
[認可サーバー]
↓ Token発行
[スマートTV]
→ ログイン完了、動画視聴開始
メリット
- UX: TVでパスワード入力不要（リモコン入力は面倒）
- セキュリティ: スマホで認証を制御
- デバイス制限なし: 入力デバイスがないIoTでも認証可能
ユースケース4: 高額取引の承認
シナリオ
[Webブラウザ] ← ユーザーが100万円の送金操作
"スマホで承認してください"
↓ 認証リクエスト（メッセージ: "100万円送金"）
[認可サーバー]
↓ プッシュ通知
[ユーザーのスマホ]
"100万円の送金を承認しますか？
送金先: ○○銀行 △△支店"
↓ 生体認証 + 取引内容確認
[認可サーバー]
↓ Token発行
[Webブラウザ]
→ 送金実行
メリット
- 取引内容確認: binding_messageで取引詳細を表示
- Step-up認証: 通常はパスワード、高額取引はスマホ承認
- フィッシング対策: ユーザーが取引内容を確認してから承認
ユースケース5: エンタープライズSSO（社員認証）
シナリオ
[社員がPCで社内システムにログイン]
↓ 認証リクエスト（ユーザー識別子: 社員番号）
[認可サーバー]
↓ プッシュ通知
[社員のスマホ（会社支給）]
"社内システムへのログイン
PC: DESKTOP-12345
承認しますか？"
↓ 生体認証 + デバイス確認
[認可サーバー]
↓ Token発行
[PC]
→ 社内システムアクセス
メリット
- デバイス確認: どのPCからのログインか確認可能
- パスワードレス: 社員はパスワード不要
- セキュリティ: 会社支給スマホで認証を制御
CIBAが適さないケース
ケース1: スマホを持っていないユーザー
問題: CIBAは別デバイス（スマホ）が必須
代替策: 従来のAuthorization Code Flow + パスワード認証
ケース2: リアルタイム性が不要
問題: ポーリングのオーバーヘッド
代替策: Authorization Code Flowの方がシンプル
ケース3: 同じデバイスで完結する認証
問題: CIBAのメリットがない
代替策: Authorization Code Flow + WebAuthn（同じデバイスで生体認証）
まとめ
CIBAが有効なシーン
- ✅ 認証要求デバイスと認証実行デバイスが異なる
- ✅ 入力デバイスがない（ATM、IoT）
- ✅ セキュリティ強化が必要（高額取引）
- ✅ UX向上が重要（パスワードレス）
CIBAが不要なシーン
- ❌ 同じデバイスで完結
- ❌ スマホを持っていないユーザー
- ❌ リアルタイム性が不要
次に読むべきドキュメント
- CIBA Flow実装ガイド - 実装方法
- Protocol: CIBA Flow - プロトコル詳細
最終更新: 2025-12-18 対象: IDサービス開発初心者