OpenID Connectの次の世界へ：FAPI・DPoP・PKCE・SSE/CAEP・Verifiable Credentials
はじめに
前回の記事（OpenID Connectの仕様を整理する）では、OIDCのコア仕様を整理しました。
本記事では、OIDCの先にある発展的なトピックを取り上げます。金融・医療などの高セキュリティ領域への対応、トークン盗難への対策、そして分散アイデンティティという新しいパラダイムまで、認証・認可の「今と未来」を俯瞰します。
1. PKCE（ピクシー）：すべてのクライアントへの必須対策
概要
** PKCE（Proof Key for Code Exchange) ** はRFC 7636で定義された、認可コード横取り攻撃への対策です。前記事でも触れましたが、改めて詳細を整理します。
仕組み
① クライアントがランダムな文字列（code_verifier）を生成
② SHA-256でハッシュ化（code_challenge）
③ 認可リクエストに code_challenge を含める
④ トークンリクエスト時に code_verifier を送信
⑤ 認可サーバーがハッシュを照合 → 一致すればトークン発行
なぜ重要か
- 認可コードが横取りされても、
code_verifierなしではトークンを取得できない - SPAやモバイルアプリなどクライアントシークレットを安全に保管できない環境では特に重要
- 現在はすべてのOAuthクライアントに推奨（FAPI 2.0では必須）
2. DPoP（ディーポップ）：トークン所有証明
概要
**DPoP（Demonstrating Proof of Possession）**はRFC 9449で定義された、トークンと送信者を紐づける仕組みです。
Bearerトークンの問題点
従来のBearerトークンは「持っているだけで使える」トークンです。
攻撃者がアクセストークンを盗む
→ そのままAPIを叩ける ← 問題
DPoPの解決策
① クライアントが公開鍵・秘密鍵ペアを生成
② APIリクエスト時に秘密鍵で署名した「DPoP証明JWT」を生成・添付
③ サーバー側でトークンと公開鍵の紐づきを検証
→ トークンを盗んでも、秘密鍵がなければ使えない
| Bearerトークン | DPoP | |
|---|---|---|
| 盗難時のリスク | 即時悪用される | 秘密鍵がないと使えない |
| 実装複雑度 | シンプル | やや複雑 |
| 採用場面 | 一般的なAPI | 金融・高セキュリティ領域 |
3. FAPI 2.0：金融グレードAPIのセキュリティ標準
概要
**FAPI（Financial-grade API）**はOpenID Foundationが策定した、金融・医療など高セキュリティ領域向けのOIDCプロファイルです。2023年にFAPI 2.0が公開されました。
FAPI 2.0の主な要件
| 要件 | 内容 |
|---|---|
| PKCEの必須化 | すべての認可リクエストでPKCEを使用 |
| DPoPの採用 | Bearerトークンではなく、DPoPで送信者を証明 |
| PAR（Pushed Authorization Requests） | 認可リクエストをサーバー間で送信（URLに機密情報を含めない） |
| RAR（Rich Authorization Requests） | 詳細な認可情報をリクエストに含める |
FAPI 2.0のセキュリティの考え方
「攻撃者がネットワーク上のすべての通信を傍受できる」
「認可サーバー以外のサーバーは信頼しない」
という厳しい脅威モデルを前提に設計されています。
日本ではOpen Bankingやマイナンバー連携などの文脈でFAPIへの対応が進んでいます。
4. SSE / CAEP：継続的アクセス評価
概要
従来の認証は「ログイン時に一度だけ確認する」モデルでした。しかし、ログイン後に以下のような状況変化が起きても、アクセストークンが有効な間はアクセスし続けられます。
- ユーザーのパスワードが変更された
- アカウントが無効化された
- デバイスが盗難に遭った
これを解決するのが**SSE（Shared Signals and Events）とCAEP（Continuous Access Evaluation Profile）**です。
仕組み
認可サーバー / IDプロバイダー
↓ セキュリティイベントをリアルタイムで通知
リソースサーバー / クライアント
↓
アクセスを即時失効・再認証を要求
SSE / CAEPが検知するイベント例
| イベント | 内容 |
|---|---|
session-revoked |
セッションが取り消された |
credential-change |
パスワード・MFAが変更された |
token-claims-change |
ユーザーの属性・権限が変わった |
device-compliance-change |
デバイスのコンプライアンス状態が変化 |
ゼロトラストセキュリティの考え方と親和性が高く、エンタープライズ領域での採用が進んでいます。
5. Verifiable Credentials：分散アイデンティティの世界
概要
これまで見てきた仕組みはすべて、中央集権的なIDプロバイダー（Google・GitHub等）に依存しています。
**Verifiable Credentials（VC）**はW3Cが策定した仕様で、ユーザー自身がアイデンティティを管理する分散型のモデルです。
登場人物
| ロール | 説明 | 例 |
|---|---|---|
| Issuer（発行者） | クレデンシャルを発行する | 大学・政府・企業 |
| Holder（保持者） | クレデンシャルを保持・提示する | ユーザー本人 |
| Verifier（検証者） | クレデンシャルを検証する | サービス事業者 |
従来モデルとの比較
【従来モデル】
ユーザー → IDプロバイダー（Google等）に問い合わせ → サービス
↑ 中央集権・プロバイダー依存
【Verifiable Credentialsモデル】
Issuer → ユーザーのウォレットにVC発行
ユーザー → 必要な情報だけをVerifierに提示（選択的開示）
↑ 分散・自己主権型
ユースケース
- デジタル学位証明：大学が発行、就職活動時に提示
- 年齢確認：生年月日を開示せず「18歳以上」だけを証明
- マイナンバーカードのデジタル化：政府発行のVCとして活用
関連技術
| 技術 | 概要 |
|---|---|
| DID（Decentralized Identifier） | 中央管理者不要の分散型識別子 |
| DID Document | DIDに紐づく公開鍵・サービス情報 |
| Wallet | VCを保管・管理するアプリ |
6. 技術の全体マップ
OAuth 2.0（RFC 6749）：認可の基盤
├── PKCE（RFC 7636）：コード横取り対策
├── DPoP（RFC 9449）：トークン所有証明
└── OpenID Connect Core 1.0：認証の追加
├── FAPI 2.0：高セキュリティプロファイル
│ ├── PKCE必須
│ ├── DPoP必須
│ └── PAR / RAR
├── SSE / CAEP：継続的アクセス評価
└── Verifiable Credentials（W3C）：分散ID
7. 参照仕様書
| 仕様書 | 概要 |
|---|---|
| RFC 7636 | PKCE |
| RFC 9449 | DPoP |
| FAPI 2.0 Security Profile | 金融グレードAPIセキュリティ |
| OpenID Shared Signals Framework | SSE |
| W3C Verifiable Credentials | 分散アイデンティティ |
まとめ
| トピック | 解決する問題 |
|---|---|
| PKCE | 認可コードの横取り |
| DPoP | アクセストークンの盗用 |
| FAPI 2.0 | 金融・医療レベルの高セキュリティ要件 |
| SSE / CAEP | ログイン後のリアルタイムリスク対応 |
| Verifiable Credentials | 中央集権IDへの依存・プライバシー |
認証・認可の世界は「ログイン時の一点確認」から「継続的・分散的・自己主権的」な方向へと進化しています。OIDCはその出発点であり、今もなお現役の重要な基盤です。
本シリーズ
- OAuth 2.0の認可フローを整理する
- OpenID Connectの仕様を整理する
- OpenID Connectの次の世界へ（本記事）