現場のエンジニア諸君、今日も泥臭いデバッグと格闘しているか？
今日は「OpenID Connect（OIDC）」の話をしよう。多くの連中が「認証さえ通れば終わり」と思っているが、真の悪夢は認証後のアクセストークン（AT）の取り扱いで始まる。特にUserInfoエンドポイントでの「スコープの甘さ」は、攻撃者にとっての「全財産が入った金庫の鍵」になり得る。
今日は、なぜ「スコープ制限」が単なる規約ではなく、死活問題なのか。そして、どう実装すれば攻撃者が入り込む隙を消せるのか、核心を突いて解説する。
—
1. なぜUserInfoエンドポイントが「狙い目」なのか？
攻撃者の視点で考えてみよう。彼らは複雑なSQLインジェクションを仕掛ける前に、まずは「何ができるか」を探る。もし君のアプリがUserInfoエンドポイントで、アクセストークンに含まれるスコープを厳密にチェックせず、全情報を垂れ流していたらどうなるか？
攻撃者は、例えば「プロフィール更新」の権限しかないはずのトークンを使い、UserInfoエンドポイントに細工したクエリを投げる。もしここで「スコープの検証漏れ」があれば、本来アクセス権のない個人情報（メールアドレス、住所、電話番号など）がごっそりと引き抜かれる。これが「権限昇格」の典型的な入り口だ。
攻撃のロジック（PoCの概念）
1. トークン入手: XSSやデバイス盗難で、特定のスコープを持つアクセストークンを奪取。
2. スコープ無視のリクエスト: openid（識別子）のみ許可されたトークンで、email や address 属性を要求する。
3. 脆弱性: バックエンドが「トークンが有効かどうか」しか見ておらず、「そのトークンに許可されたスコープで要求されているか」を検証していない。
結果：機密情報の漏洩（情報漏洩インシデントの完成）。
—
2. 対策の鉄則：最小権限の原則（Scope Validation）
解決策はシンプルだ。「トークンはただのチケットではなく、許可証である」と認識すること。UserInfoエンドポイントでは、以下の処理を強制する。
1. トークンの署名検証（これは基本中の基本）。
2. 有効期限（exp）のチェック。
3. 要求された属性と、トークン内のスコープの照合（ここが最重要）。
—
3. 実装サンプル：Python (FastAPI) での厳密なスコープ検証
多くのフレームワークはスコープチェックを実装しているが、デフォルト任せにするな。自分で明示的にガードレールを置くんだ。
from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
OAuth2のスコープを定義
oauth2_scheme = OAuth2PasswordBearer(tokenUrl=”token”)
def verify_scope(required_scope: str):
“””
トークン内のスコープを検証する依存関数
“””
def validator(token: str = Depends(oauth2_scheme)):
# 実際にはここでJWTをデコードし、’scope’クレームを確認する
# decoded_token = decode_and_verify(token)
# 擬似的な検証ロジック
user_scopes = [“openid”, “profile”] # トークンから抽出したスコープ
if required_scope not in user_scopes:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail=”このスコープでのアクセスは許可されていません。”
)
return True
return validator
app = FastAPI()
特定のUserInfoエンドポイント：’email’スコープが必要なケース
@app.get(“/userinfo/email”, dependencies=[Depends(verify_scope(“email”))])
async def get_user_email():
return {“email”: “victim@example.com”}
—
4. インフラ側での防御：Nginxによるヘッダー制御
アプリケーション側の実装も大事だが、万が一の漏洩に備えて、出口（Egress）も締める。APIゲートウェイやNginxで、特定のパスへのアクセスには特定のスコープを要求するように設定するのも有効な多層防御だ。
Nginx設定例：特定のエンドポイントには認証ヘッダーを厳密にチェックさせる
location /api/v1/userinfo/ {
# 認可サーバーへトークンの有効性とスコープを問い合わせるためのサブクエスト設定
auth_request /auth-verify;
# 認可サーバーからのレスポンスをヘッダーにセット
auth_request_set $auth_status $sent_http_x_scope_status;
# スコープが不足している場合は403を返す
if ($auth_status = “denied”) {
return 403;
}
proxy_pass http://backend_app;
}
—
最後に：セキュリティは「性悪説」で設計せよ
現場で最も恐ろしいのは、「ここは内部ネットワークだから大丈夫」「認証は通っているから中身は安全だろう」という慢心だ。
アクセストークンのスコープ制限は、「もしトークンが盗まれても、被害を最小限に抑える」ための防波堤だ。UserInfoエンドポイントにリクエストが来るたびに、毎回「このトークンには、この情報を渡していいのか？」と問いかけてほしい。
コードを書くとき、その一行が「攻撃者の侵入経路」にならないか。常に一歩引いてシステム全体を俯瞰する視点を持つこと。それが、俺たちが目指すべきエンジニアの姿だ。
さて、コードに戻ろう。今日の修正は、明日以降の「深夜の緊急インシデント対応」を未然に防ぐための投資だと思って取り組んでくれ。健闘を祈る。
コメント