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はその出発点であり、今もなお現役の重要な基盤です。

本シリーズ