OIDC/OAuthクライアントシークレットの期限切れ・漏えい時に、停止を避けて安全に更新する実務手順。新旧secret併用、設定反映、ログ確認、旧secret無効化、PKCEや証明書・フェデレーション資格情報への移行判断、台帳整備まで整理します。
冒頭要約
OIDCやOAuth 2.0で使うクライアントシークレットは、Webサーバー側アプリやバックエンドサービスが認可サーバーへ「自分は登録済みアプリである」と示すための資格情報です。値が期限切れになる、古い設定が残る、リポジトリやCIログへ漏れると、ログイン停止、トークン交換失敗、外部API連携停止、漏えい疑いの初動対応につながります。
まず確認するのは、対象アプリ、client ID、secretの用途、有効期限、保存先、利用している環境、ロールアウト方式、監査ログ、旧secretの無効化タイミングです。Googleの公式情報では、新旧secretを併用できる間にアプリを新secretへ移行し、ログや設定で旧secretが使われていないことを確認してから旧secretを無効化する流れが示されています。
この記事では、情シス、SaaS管理者、開発者、SRE向けに、OIDC/OAuthクライアントシークレットの更新手順、期限切れ・漏えい時の初動対応、判断基準、よくある誤解を整理します。攻撃再現、secretの悪用、認証回避、探索手順は扱いません。
調査・報告で必要なのは、secretの値ではなく、client ID、対象アプリ、credential ID、作成日時、有効期限、保存先、失効・再発行の時刻です。secret値をチャット、スクリーンショット、チケット本文へ貼ると、二次漏えいの原因になります。
読者別の影響：誰が何を見るべきか
クライアントシークレットは、ログイン画面の裏側、SaaS連携、CI/CD、バッチ処理、Webhook受信、外部API連携などに残りやすい資格情報です。単に「開発者が環境変数を差し替える」だけでなく、利用者影響、監査ログ、ロールバック、代替認証方式まで関係します。
| 読者・担当者 | まず見るもの | 見落としたときの問題 |
|---|---|---|
| 開発者 | アプリ設定、環境変数、secret manager、デプロイ済みバージョン | 新secretへ切り替えたつもりでも、一部Podやバッチが旧secretを使い続ける |
| SRE / DevOps | CI/CD secrets、Kubernetes Secret、クラウドSecret Manager、ロールアウト状況 | デプロイ失敗、トークン交換失敗、夜間バッチ停止、復旧経路喪失が起きる |
| 情シス・SaaS管理者 | OAuthクライアント一覧、client ID、所有者、リダイレクトURI、利用部門 | 退職者所有のアプリ、用途不明のsecret、古い連携が残る |
| セキュリティ担当 | secretの保存先、権限、scope、最終利用、監査ログ、漏えい検知 | 失効対象を誤り、実際に使われた可能性のある経路を見落とす |
| ヘルプデスク | 利用者影響、ログイン失敗文言、問い合わせ時刻、回避策 | 「パスワードリセットで直る」と誤案内し、初動が遅れる |
基礎用語を整理したい場合は、OAuth 2.0、OpenID Connect、JWT、Access Token、Refresh Tokenを先に確認してください。SAML証明書更新との違いは、SAMLとOIDCの違いと前回の記事が参考になります。
クライアントシークレットとは：OIDC、OAuth、SAML証明書との違い
OIDCはOAuth 2.0の上に認証レイヤーを追加する標準で、ID Tokenを使って「誰がログインしたか」を伝えます。一方、OAuth 2.0は「どのアプリに、どの範囲のアクセスを許可するか」という認可の仕組みです。どちらも、サーバー側アプリがトークンエンドポイントで自分を認証するために、client secretを使う場合があります。
実務では、次の違いを混同しないことが重要です。
| 用語 | 主な意味 | 確認ポイント |
|---|---|---|
| client ID | アプリを識別する公開寄りのID | 値自体はsecretではないが、誤ったアプリと混同しない |
| client secret | confidential clientが認可サーバーへ提示する共有secret | 保存先、有効期限、利用環境、旧secret無効化タイミングを確認する |
| redirect URI | 認可コードや応答を返す先 | 本番・検証・ローカルの登録差分、不要URI、HTTPSを確認する |
| access token | APIアクセスに使う短命トークン | scope、audience、有効期限、漏えい時の失効可否を確認する |
| refresh token | access tokenを再取得するためのトークン | 長期利用、保存先、ローテーション、失効手順を確認する |
| SAML証明書 | SAML response/assertionなどの署名検証に使う証明書 | metadata、証明書期限、SP側更新、署名方式を確認する |
IETF OAuth 2.0仕様では、confidential clientは資格情報を安全に保持できるクライアント、public clientは保持できないクライアントとして扱われます。GitHubの公式情報も、Webアプリなどのconfidential clientではsecretを安全な保管先に置く一方、ネイティブアプリ、CLI、SPAのようなpublic clientではsecretを安全に守れないため、PKCEを使うべきだと説明しています。
ブラウザSPA、モバイルアプリ、デスクトップアプリ、CLIに埋め込んだsecretは、利用者環境へ配布されます。名前にsecretと付いていても安全に秘匿できないため、PKCE、BFF、サーバー側トークン交換、別方式への移行を検討します。
まず確認すること：OIDC/OAuth secret更新チェックリスト
期限切れ通知、漏えい疑い、Secret Scanningアラート、SaaS連携停止を受け取ったら、いきなり旧secretを削除せず、次の項目を台帳化します。
| 確認項目 | 見るポイント | 記録すること |
|---|---|---|
| 1. 対象アプリ | OAuthクライアント名、client ID、所有部門、利用サービス | アプリ名、client ID、環境、本番/検証 |
| 2. 用途 | ログイン、API連携、バックエンドバッチ、CI/CD、Webhook | 認証方式、利用フロー、利用者影響 |
| 3. 有効期限 | 期限切れまでの日数、通知先、過去の更新履歴 | 有効期限、作成日時、credential ID |
| 4. 保存先 | secret manager、環境変数、CI/CD secret、Kubernetes Secret、設定ファイル | 保存場所、参照しているサービス、更新担当 |
| 5. ロールアウト | 新旧secret併用可否、最大secret数、反映遅延、再起動要否 | 切替手順、影響範囲、戻し条件 |
| 6. ログ確認 | トークンエンドポイント失敗、sign-in log、APIログ、アプリログ | 成功/失敗時刻、エラー種別、旧secret使用有無 |
| 7. 旧secret | 無効化、削除、再有効化可否、削除期限 | 無効化時刻、削除時刻、承認者 |
| 8. 漏えい疑い | リポジトリ、CIログ、チャット、端末、チケットへの露出 | 露出場所、発見者、失効・再発行時刻 |
| 9. 代替方式 | 証明書、フェデレーション資格情報、Workload Identity、PKCE | 移行可否、期限、担当者 |
| 10. 連絡 | 影響ユーザー、ヘルプデスク、開発チーム、SaaSオーナー | 周知文、問い合わせ先、変更チケット |
Microsoft Entraの公式情報では、アプリ資格情報の期限切れが近い場合、アプリ登録のCertificates & secretsから新しい証明書またはclient secretを追加し、サービスコードを新資格情報へ更新し、サインインログで新しいKey IDを確認してから旧資格情報を削除する流れが示されています。Googleの公式情報では、OAuthクライアントは最大2つのclient secretを持てるため、新secretを作り、アプリ設定・ログ・ロールアウト状況を確認してから旧secretを無効化・削除する手順になっています。
初動対応：やること、やらないこと、記録すること
やること
- 期限切れ通知や漏えい疑いを受けたら、対象client ID、環境、保存先、所有者、利用フローを確認する。
- 新secretを作成したら、secret managerやCI/CD secretsなど正規の保管先へ登録し、コードやチャットに値を残さない。
- 本番へ反映する前に、検証環境または限定された本番経路でトークン交換、ログイン、API呼び出しを確認する。
- 新旧secretを併用できる場合は、旧secretが使われなくなったことをアプリログ、認可サーバーログ、ロールアウト状況で確認する。
- 旧secretを無効化した直後は、ログイン失敗、バッチ失敗、APIエラー、ヘルプデスク問い合わせを監視する。
- 本番で長期secretを使い続けている場合は、証明書、フェデレーション資格情報、Workload Identity、短命トークンへ置き換えられるか検討する。
やらないこと
- 期限切れ直前に、テストなしで旧secretを削除しない。
- secret値をチケット、チャット、issue、PR、Wiki、手順書に貼らない。
client_idとclient_secretを混同し、公開してよい値と秘匿すべき値を同じ扱いにしない。- public clientにsecretを埋め込んで「秘匿できている」と扱わない。
- 漏えい疑いのあるsecretで、第三者環境や本番APIへ「使えるか」を試さない。
- 旧secretを無期限に残して「ロールバック用」と呼ばない。
記録すること
| 記録項目 | 例 |
|---|---|
| 対象 | client ID、アプリ名、環境、所有者、利用フロー |
| secret | credential ID、作成日時、有効期限、保存先、旧/新の区別 |
| 作業 | 作成、設定反映、デプロイ、検証、無効化、削除の時刻 |
| ログ | トークン交換成功/失敗、sign-in log、APIエラー、アプリログ |
| 判断 | 継続、ロールバック、旧secret削除延期、方式移行、CSIRT連携 |
GitHubリポジトリやCI/CDログにsecretが出た疑いがある場合は、GitHub secret leak対応チェックリストとGitHub Secret Scanningアラート初動対応を併用してください。開発ツールや依存関係侵害をきっかけに資格情報を見直す場合は、開発ツール・OSSサプライチェーン確認チェックリストへ進むと、CI/CDやクラウド資格情報まで広げて確認できます。
判断基準：優先度とエスカレーション条件
クライアントシークレット更新の優先度は、期限までの日数だけでは決まりません。対象アプリの重要度、secretの権限、漏えい可能性、代替手段で判断します。
| 優先度 | 状況 | 初動判断 |
|---|---|---|
| 高 | 期限切れまで7日以内、またはすでに期限切れ | 変更枠を確保し、所有者、SRE、ヘルプデスク、セキュリティ担当を同じチケットに入れる |
| 高 | production login、顧客向けSaaS、決済、クラウド管理、GitHub連携で使う | 新secret作成とログ確認を優先し、失敗時のロールバック条件を決める |
| 高 | secretがリポジトリ、CIログ、チャット、端末、チケットへ露出した疑いがある | 漏えい疑いとして失効・再発行し、利用ログと影響範囲を確認する |
| 高 | public clientにsecretが埋め込まれている | secret前提をやめ、PKCEやサーバー側フローへ設計変更を検討する |
| 中 | 新旧secret併用は可能だが、旧secret使用有無のログが不足している | 監視期間を設け、アプリログ・認可サーバーログ・メトリクスを追加確認する |
| 低 | 検証環境、期限まで60日以上、所有者と保存先が明確 | 通常変更として計画し、台帳と通知先を更新する |
Microsoft Entraでは、client secret lifetimeは24か月以下で、12か月未満の期限設定が推奨されています。また、本番ではclient secretよりも証明書やフェデレーション資格情報を優先する説明があります。つまり、期限切れ対応を単発作業で終わらせず、「このsecretを今後も持ち続けるべきか」を合わせて判断します。
よくある誤解
「client IDが漏れたので即インシデント」
client IDはアプリ識別子であり、通常はclient secretほど秘匿性が高い値ではありません。ただし、client ID、redirect URI、アプリ名、scope、secretがセットで漏れると影響が変わります。値ごとに扱いを分けます。
「secretを再発行したので旧secretはすぐ消してよい」
アプリ、バッチ、CI/CD、古いPod、ジョブワーカーが旧secretを使っている場合、即削除で停止します。新secretが全経路で使われていることをログで確認してから旧secretを無効化します。
「環境変数に入れているから安全」
環境変数は便利ですが、ログ出力、クラッシュダンプ、管理画面、CI/CD設定、権限の広い閲覧者から見える場合があります。専用のsecret manager、アクセス制御、監査ログ、ローテーションを合わせて考えます。
「SPAにclient secretを入れればセキュリティが上がる」
SPAやモバイルアプリはpublic clientであり、配布されたコードや端末上の値を安全に秘匿できません。PKCEやBFF、サーバー側トークン交換を検討します。
「PKCEを使えばclient secretは不要な場面でも全て安全」
PKCEはpublic clientの認可コード横取りリスクを下げる仕組みですが、すべての認可・認証リスクを解決するものではありません。redirect URI、state、nonce、token保存、scope、セッション管理も確認します。
関連用語・関連ページ
公式情報・参考情報
- Microsoft Learn: Renew expiring application credentials — Microsoft Entraで期限切れが近いアプリ資格情報を更新し、サービスコード更新、サインインログ確認、旧資格情報削除へ進む流れを確認できる。
- Microsoft Learn: Add and manage application credentials in Microsoft Entra ID — client secretの期限、証明書やフェデレーション資格情報の扱い、client secret値が再表示されない点を確認できる。
- Google Cloud Help: Manage OAuth Clients — Google OAuthクライアントのsecret作成、アプリ反映、旧secret無効化、削除、最大secret数を確認できる。
- GitHub Docs: Best practices for creating an OAuth app — OAuth Appのclient secret保管、confidential clientとpublic client、PKCEの考え方を確認できる。
- OpenID Connect Core 1.0 — OIDCがOAuth 2.0上の認証レイヤーであり、ID Tokenなどを扱う標準であることを確認できる。
- RFC 6749: The OAuth 2.0 Authorization Framework — OAuth 2.0におけるclient type、client credentials、認可フレームワークの基礎を確認できる。
- RFC 7636: Proof Key for Code Exchange by OAuth Public Clients — public client向けにPKCEが定義された背景と位置づけを確認できる。
- OWASP Cheat Sheet: Secrets Management — secret rotationを安全に進める段階的な考え方を確認できる。
まとめ
OIDC/OAuthクライアントシークレットの更新は、「新しい値を作って環境変数を差し替える」だけでは終わりません。対象アプリ、client ID、保存先、利用環境、ロールアウト、ログ確認、旧secret無効化、削除、漏えい疑いの有無まで一連の変更として扱います。
特に、本番ログインや外部API連携、CI/CD、クラウド管理で使うsecretは、期限切れ前から台帳化し、通知先と所有者を明確にします。漏えい疑いがある場合は、secret値を共有せず、失効・再発行、ログ確認、再発防止を優先します。
次に実務へ落とすなら、GitHub secret leak対応チェックリストに「OIDC/OAuth client secret」「保存先」「旧secret使用有無」「PKCE・フェデレーション資格情報への移行可否」を追加し、四半期ごとのSaaS・開発基盤棚卸しで確認してください。
