OIDCの罠：UserInfoエンドポイントにおける「スコープ過剰付与」という静かなる崩壊
セキュリティアーキテクトとして多くのコードベースを監査してきたが、IDトークンやアクセストークンの検証については、「標準プロトコルに従っているから安全だ」という甘美な思い込みが最も致命的な脆弱性を生む。特にOpenID Connect (OIDC) の UserInfo エンドポイントの実装において、アクセストークンのスコープ検証を単なる「存在確認」で済ませているケースが後を絶たない。
これは、認可の境界線における「論理的なメモリリーク」とも呼べる事象だ。今回は、この盲点がどのように攻撃者に悪用されるのか、そしてそれを防ぐための堅牢なアーキテクチャ設計について掘り下げていこう。
1. 脆弱性の本質：スコープとリソースの「断絶」
多くの開発者は、OAuth 2.0のアクセストークンを「単なる通行手形」と誤解している。しかし、UserInfoエンドポイントは、リソースサーバーの側面を持つと同時に、アイデンティティのプロバイダーとしての側面を持つ。
脆弱性が生まれる典型的なフローはこうだ。
1. クライアントが scope=openid profile で認証を行う。
2. 認可サーバーがアクセストークンを発行。
3. クライアントが UserInfo エンドポイントにトークンを投げる。
4. 実装の欠陥： サーバー側が「トークンが有効か」のみを確認し、そのトークンが profile スコープを内包しているか（あるいは、リクエストされた属性に対して権限があるか）を厳密に検証していない。
もしバックエンド側で、トークンに含まれるスコープのクレーム（scp または scope）を無視してユーザー情報を返却するように実装されている場合、攻撃者は「本来許されていない権限」で、ユーザーの機密属性（電話番号や住所、あるいはカスタムクレーム）を抽出可能になる。これはIDOR（Insecure Direct Object Reference）の亜種であり、プロトコル層の仕様漏れを突く攻撃だ。
2. 防御的実装：スコープ検証の厳格化
アーキテクトとして推奨すべきは、単なるバリデーションではなく、「スコープに基づいた属性フィルタリング」の実装である。以下に、Go言語を用いたミドルウェアレベルの検証例を示す。
// UserInfoエンドポイントの認可ロジック例
func UserInfoHandler(w http.ResponseWriter, r http.Request) {
// 1. トークンの抽出とデコード（JWTの場合）
token := extractBearerToken(r)
claims := decodeAndVerifyJWT(token)
// 2. スコープの検証：要求された情報の整合性を確認
scopes := strings.Split(claims.Scope, ” “)
hasProfileScope := contains(scopes, “profile”)
hasEmailScope := contains(scopes, “email”)
// 3. 属性フィルタリング：スコープに基づいた動的なレスポンス構築
userData := fetchUserFromDatabase(claims.Subject)
response := map[string]interface{}{}
if hasProfileScope {
response[“name”] = userData.Name
response[“picture”] = userData.Picture
}
if hasEmailScope {
response[“email”] = userData.Email
response[“email_verified”] = userData.EmailVerified
}
// クレームに含まれない情報を返さないことが重要
json.NewEncoder(w).Encode(response)
}
このコードの肝は、データベースから取得したユーザー情報をそのまま返すのではなく、スコープという「鍵」によってホワイトリスト的にフィルタリングしている点にある。
3. 次世代の脅威：プロンプトインジェクションとOIDC
現代のシステムでは、AIエージェントがUserInfoエンドポイントを呼び出すケースが増えている。ここで注意すべきは、生成AIが持つ「プロンプトインジェクション」によるサイドチャネル攻撃だ。
攻撃者は、LLMに対して「UserInfoエンドポイントのレスポンスを細工せよ」と命令し、モデルが本来持っていないはずの属性を推論・抽出させようとする。これに対抗するには、以下のガードレイル設計が不可欠だ。
- 構造化されたスキーマ強制: APIのレスポンスにJSON Schemaを適用し、AIが想定外のフィールドを参照できないよう、物理的なデータ境界を設ける。
- Context-Aware Logging: アクセストークンのスコープと、アクセスされた属性の組み合わせを監査ログに残す。AIによる自動抽出が発生した場合、このログの「スコープ外アクセス」を異常検知エンジンが即座にフラグ立てする必要がある。
4. 最後に：セキュリティは「仕様の行間」に宿る
耐量子暗号（PQC）への移行が議論される現在、暗号の強度ばかりが注目されがちだが、結局のところ攻撃者が突くのは、今回のような「認可とスコープの論理的整合性」の欠落だ。
プロトコルの仕様書を隅々まで読むのは当然として、その先の「実装者が何を省略したがるか」という心理的な脆弱性こそが、我々ホワイトハッカーが真に注視すべき領域である。コードを書く際、常に自問してほしい。「このアクセストークンは、このデータにアクセスするために本当に十分な権限を持っているか？」と。
この問いを繰り返すことこそが、強固なゼロトラスト・アーキテクチャの礎となる。技術は常に進化するが、セキュリティの本質は変わらない。境界線を疑い、信頼を最小化せよ。それが、システムを生き残らせる唯一の道だ。
コメント