OAuth/OIDCの非推奨フロー兆候とは？Implicit flow・ROPCのリスクと移行方法・診断基準

OAuth/OIDCの非推奨フロー兆候とは

OAuth/OIDCの非推奨フロー兆候とは、Webページのソースやリンク先URLの中に、OAuth 2.0／OpenID Connectで現在は使うべきでないとされたフローを示すパラメータが含まれていることです。具体的には次の2つです。

セキュリティAIチェッカーのこの項目は、巡回したページのHTMLとURLの中にこれらのパラメータがないかを確認します。HTMLやURLに文字列があることは、そのフローが実際に使われていることの「兆候」にすぎず、文書や使われていないコードの可能性もあります。そのため検出時は×（fail）ではなく△（warn）とし、実際の構成確認を促します。

Implicit flowとROPCはなぜ非推奨になったのか

Implicit flow（response_type=token）

シングルページアプリ向けに、認可サーバーがアクセストークンをリダイレクトURLのフラグメント（#access_token=...）に入れて直接返す方式です。トークンがブラウザ履歴、Referer、ブラウザ拡張、オープンリダイレクトなどを経由して漏れやすく、送信者制約（トークンを特定のクライアントに結び付ける仕組み）も掛けられません。

RFC 9700（2025年1月発行のOAuth 2.0セキュリティBCP）§2.1.2は、クライアントはImplicit grant（response type token）や、認可応答でアクセストークンを発行する他のレスポンス種別を使うべきではなく（SHOULD NOT）、代わりに code などを使うべきだとしています。token id_token や code token のように token を含む組み合わせも同じ扱いです。

Resource Owner Password Credentials（grant_type=password）

クライアントアプリが利用者のIDとパスワードを受け取り、そのままトークンエンドポイントへ送る方式です。パスワードをクライアントに渡すことになり、多要素認証や複数段階の認証は想定されておらず、WebAuthnなどの暗号学的な認証は実装できない場合があります。RFC 9700 §2.4は「使ってはならない（MUST NOT）」と明記しています。

標準・仕様の位置付け

推奨されるフロー

• Authorization Code + PKCE：認可コードをリダイレクトで受け取り、トークンはバックチャネル（トークンエンドポイント）で取得します。PKCE（code_challenge／code_verifier）で認可コードの横取りを防ぎます。SPAやスマートフォンアプリでも使えます。
• BFF（Backend for Frontend）：トークンをサーバー側で保持し、ブラウザにはHttpOnly Cookieのセッションだけを渡す構成は、SPAでトークン漏えいを避ける有力な方法です。

response_type=id_token 単独は非推奨フローではない

OpenID Connectの response_type=id_token は、本人確認用のIDトークンだけを返し、アクセストークンは発行しません。ASVS V10.6.1は、OpenID Providerが許可してよい値として id_token を明示的に含めており、RFC 9700 §2.1.2の対象も「アクセストークンを認可応答で発行する」レスポンス種別です。このため本診断は id_token 単独を非推奨フローとして扱いません（ただしnonce検証などOIDCの要件を満たすことは前提です）。

OAuthのフローについてよくある誤解

• 「SPAだからImplicitしか使えない」：現在はブラウザのCORS対応によりSPAでもAuthorization Code + PKCEが使えます。主要なIDaaSのSDKも既定でPKCEを使います。
• 「自社アプリだからROPCで問題ない」：パスワードを扱う経路が増えるだけでなく、多要素認証の導入時に作り直しが必要になります。

OAuth/OIDCの非推奨フロー兆候の診断基準（セキュリティAIチェッカー）

取得方法

1. トップページのHTML全文（最大2MB）と、追加取得した下層ページ（最大2件、1ページあたり最大180KB）の本文。
2. 抽出した同一オリジンのURL一覧（リンク、フォーム送信先、JavaScript内のURL、巡回候補）。
3. これらを連結したテキストに対して文字列パターンを照合します。追加のネットワーク取得は行いません。

非推奨フローの検出条件

判定条件

• response_type=code、code id_token（OIDC Hybrid）、id_token 単独はpassです。
• access_token や id_token_hint のような別名のパラメータは、response_type の値ではないため対象になりません。
• failにしない理由：文字列の存在だけでは、実際にそのフローで認可サーバーが応答するか、OAuthの解説文書か、使われていないSDKのコードかを区別できないためです。warnの場合は、どのページ・どのスクリプトに含まれていたかを確認してください。
• 外部ドメインにある認可サーバー側の設定（許可グラントの制限）は確認できません。
• redirect_uri を悪用したオープンリダイレクトは「外部URLパラメータへのオープンリダイレクト」で確認します。

自治体サイトでの判定例

非推奨フローを使い続けるとどんなリスクがあるか

• アクセストークンの漏えい：Implicit flowでは、URLフラグメントに入ったトークンがブラウザ履歴や、リダイレクト先ページのスクリプト、オープンリダイレクトを経由して攻撃者に渡ることがあります。漏れたトークンは、利用者になりすましてAPIを呼ぶのに使われます。
• トークン差し替え：Implicit flowではクライアントがトークンの発行先を確実に検証しにくく、別クライアント向けのトークンを受け入れてしまう問題が知られています。
• パスワードの集中と流出：ROPCではクライアントが利用者のパスワードを直接扱うため、クライアントの脆弱性やログからパスワードが流出し、パスワード使い回しによる他サービスへの被害にもつながります。
• 多要素認証の不在：ROPCはパスワードだけで完結する前提のため、多要素認証やフィッシング耐性のある認証を組み込みにくく、パスワードリスト攻撃に弱くなります。

Authorization Code＋PKCEへの移行方法（Keycloak・JavaScript・サーバー側）

移行の方針

認可リクエストの例（Authorization Code + PKCE）

GET /authorize?response_type=code
  &client_id=example-client
  &redirect_uri=https%3A%2F%2Fwww.example.lg.jp%2Fcallback
  &scope=openid%20profile
  &state=ランダム値
  &nonce=ランダム値
  &code_challenge=BASE64URL(SHA256(code_verifier))
  &code_challenge_method=S256

Keycloakの設定例

クライアント設定で「Implicit flow」と「Direct access grants」（ROPCに相当）を無効にし、「Standard flow」のみを有効にします。PKCEは「Proof Key for Code Exchange Code Challenge Method」を S256 にします。

JavaScript（oidc-client-ts の例）

import { UserManager } from "oidc-client-ts";

const userManager = new UserManager({
  authority: "https://idp.example.lg.jp/realms/city",
  client_id: "city-portal",
  redirect_uri: "https://www.example.lg.jp/callback",
  response_type: "code",      // token / id_token token は使わない
  scope: "openid profile",
});

サーバー側のROPC廃止

// 悪い例：利用者のパスワードを受け取りトークンを取得
// body: new URLSearchParams({ grant_type: "password", username, password })

// 良い例：認可コードとcode_verifierでトークンを取得
const body = new URLSearchParams({
  grant_type: "authorization_code",
  code,
  redirect_uri: "https://www.example.lg.jp/callback",
  client_id: "city-portal",
  code_verifier,
});

移行後の確認方法

# 公開ページに非推奨フローの兆候が残っていないか
curl -s https://www.example.lg.jp/ | grep -ioE 'response_type["'"'"']?\s*[:=]\s*["'"'"']?[a-z_+ ]+|grant_type["'"'"']?\s*[:=]\s*["'"'"']?password'

# 認可サーバーがImplicitを拒否するか（unsupported_response_type等のエラーが期待値）
curl -s -o /dev/null -D - 'https://idp.example.lg.jp/authorize?response_type=token&client_id=city-portal&redirect_uri=https%3A%2F%2Fwww.example.lg.jp%2Fcallback' | grep -i '^location'

ログインを壊さないための注意点

• 認可サーバー側でImplicitを止める前に、そのクライアントを使う全アプリが移行済みであることを確認してください。先に止めるとログインできなくなります。
• redirect_uri は認可サーバーで完全一致登録にします（ASVS V10.4.1）。部分一致を許すと、オープンリダイレクトと組み合わせた認可コード窃取の原因になります。
• warnの原因が解説記事やサンプルコードの場合は、公開ページから削除するか、実運用で使っていないことを記録しておくと、次回診断時の説明が容易になります。

よくある質問（FAQ）

参考資料

• RFC 9700 Best Current Practice for OAuth 2.0 Security
• OWASP ASVS 5.0.0 V10 OAuth and OIDC
• RFC 7636 Proof Key for Code Exchange by OAuth Public Clients
• OpenID Connect Core 1.0
• OAuth 2.0 Implicit Grant Type（oauth.net）
• OAuth 2.0 Password Grant Type（oauth.net）

「OAuth/OIDCの非推奨フロー兆候」と関連する診断項目

• 外部URLパラメータへのオープンリダイレクトhigh
• クライアント保存値を認証判定に使っていないcritical
• Refererをアクセス制御に使っていないcritical
• 認証後コンテンツを静的ファイルで直接配信していないcritical
• Cookie・Referer偽装でアクセス範囲が増えないcritical
• 認証後静的ファイルの未認証到達性critical
• 未認証APIの情報露出兆候high