OIDC UserInfoエンドポイントの深淵：認可の「隠れた境界線」をどう守るか
セキュリティ・アーキテクトとして多くの現場を渡り歩いてきたが、依然としてアプリケーション開発の最前線で「UserInfoエンドポイント」が単なるデータ取得APIとして軽視されているケースが後を絶たない。
OpenID Connect (OIDC) の仕様は一見堅牢だが、実装者が「アクセストークンがあるから認証・認可はクリアしているはず」と安易に解釈した瞬間に、そのシステムは脆弱性の温床へと変貌する。本稿では、UserInfoエンドポイントを巡るPII（個人識別情報）の保護と、実戦的な防御アーキテクチャについて、泥臭いレイヤーから紐解いていく。
—
1. 認可チェックの「盲点」：アクセストークンを過信するな
多くのエンジニアが犯す最大の過ちは、UserInfoエンドポイントにおいて「アクセストークンの有無」を「権限の正当性」と直結させてしまうことだ。
アクセストークンは、あくまで「あるリソースに対してアクセスを許可された証明」に過ぎない。もし、異なるスコープ（例：`openid`のみ vs `profile email`）を持つ複数のクライアントが存在する場合、UserInfoエンドポイント側で以下の認可チェックを怠れば、特権昇格やPIIの漏洩（IDOR: Insecure Direct Object Reference）に直結する。
実装時のアーキテクチャ・ガードレール
UserInfoエンドポイントでは、以下のプロセスを必須のパイプラインとして組み込むべきだ。
// GoでのUserInfoハンドラ実装例（概念）
func UserInfoHandler(w http.ResponseWriter, r http.Request) {
// 1. トークンの検証（署名、有効期限、Audience）
token := extractBearerToken(r)
claims, err := validateToken(token)
if err != nil {
http.Error(w, “Unauthorized”, http.StatusUnauthorized)
return
}
// 2. 厳密なスコープチェック
// 単にトークンが有効かではなく、リクエストされた属性に必要なスコープが
// トークンに含まれているかを検証する
if !claims.HasScope(“profile”) {
http.Error(w, “Insufficient Scope”, http.StatusForbidden)
return
}
// 3. PIIマスキング（重要）
// AIエージェントなどが介在する場合、PIIを動的にフィルタリングする層を設ける
userProfile := fetchUserProfile(claims.Subject)
maskedProfile := applyPrivacyPolicy(userProfile, claims.ClientID)
json.NewEncoder(w).Encode(maskedProfile)
}
—
2. PII保護の深層：パケット構造から見えるリスク
UserInfoエンドポイントから返却されるJSONレスポンスは、攻撃者にとっての「宝の山」だ。特にPIIの保護において、TLSの終端ポイントとバックエンドの境界でデータが平文で流れる設計は、インフラ側の不備を突く標的となる。
耐量子暗号（PQC）を見据えた通信設計
今後数年以内に、現在のRSA/ECDSAベースの通信は「Store Now, Decrypt Later」攻撃の脅威に晒される。UserInfoエンドポイントのセキュアな実装を考えるのであれば、以下の二点を意識したアーキテクチャを設計せよ。
- Hybrid Key Exchange: TLS 1.3において、従来のECDHEに加えてKyberなどのPQCアルゴリズムを組み合わせたハイブリッド鍵交換を導入すること。
- Application Layer Encryption (ALE): PIIが含まれるペイロードそのものを、JWE (JSON Web Encryption) で保護し、API Gatewayから先は特定のバックエンドしか復号できない状態を維持する。
—
3. 生成AI時代の新たな脅威：プロンプトインジェクションとUserInfo
現在、我々が直面している最大の変化は、UserInfoエンドポイントが「人間」ではなく「AIエージェント」から呼び出される機会が激増している点だ。
AIエージェントにUserInfoを渡す際、そのトークンが持つスコープが広すぎると、エージェントが意図せずプロンプトインジェクションの踏み台となり、PIIを外部の悪意あるドメインへ送信するリスクがある。
防御の要：ガードレイル・アーキテクチャ
UserInfoエンドポイントの前に、「Context-Aware Privacy Proxy」を設置せよ。
1. 認可のコンテキスト化: 呼び出し元のClient IDだけでなく、リクエストが「AIエージェント」からのものか、「UIフロントエンド」からのものかを判定し、スコープを動的に制限する。
2. 出力モニタリング: LLMへPIIを渡す直前に、個人情報のパターンマッチング（電話番号、住所、SSN等）を行い、必要に応じて匿名化（トークン化）するフィルタリングレイヤーを設けること。
—
結びに代えて：セキュリティは「仕様」ではなく「規律」
OIDCの仕様書を読み込むことは出発点に過ぎない。真のセキュリティアーキテクトは、パケットがネットワークを流れる過程でのメモリ上の挙動、あるいはAPIがAIという新しいインターフェースと結合する際の「予期せぬ挙動」にまで想像力を巡らせる。
UserInfoエンドポイントの保護は、単なるバリデーションの積み重ねではない。それは、システムに刻み込む「誰が、何のために、どの範囲のPIIにアクセスできるのか」という厳格な規律そのものだ。
君たちの設計が、次のCVEを未然に防ぐ防波堤となることを期待している。
コメント