OIDCクライアントシークレット更新手順 ─ OAuthログイン停止とsecret漏えいを避ける確認方法

冒頭要約

OIDCやOAuth 2.0で使うクライアントシークレットは、Webサーバー側アプリやバックエンドサービスが認可サーバーへ「自分は登録済みアプリである」と示すための資格情報です。値が期限切れになる、古い設定が残る、リポジトリやCIログへ漏れると、ログイン停止、トークン交換失敗、外部API連携停止、漏えい疑いの初動対応につながります。

最初に、漏えいのない計画更新か、漏えい疑いの緊急対応かを分けます。計画更新では、新secretを配布して全利用経路の反映を確認し、旧secretを停止します。漏えい疑いでは、通常の監視期間を待つことで悪用可能な時間を延ばさず、責任者と緊急失効・サービス制限を判断します。

この記事では、情シス、SaaS管理者、開発者、SRE向けに、OIDC/OAuthクライアントシークレットの更新手順、期限切れ・漏えい時の初動対応、判断基準、よくある誤解を整理します。攻撃再現、secretの悪用、認証回避、探索手順は扱いません。

困っている状態から進む：計画更新か漏えい対応かを分ける／Entra・Googleで先に確認する違い／更新後も失敗する場合／更新記録を使う。利用者のパスワードとアプリのclient secretは別物なので、ログイン障害を利用者のパスワードリセットだけで直そうとしないでください。

• 状況を分ける

  計画更新か漏えい疑いか。対象アプリ・権限・利用経路・影響を確認する。

• 切替と失効

  計画更新は反映確認、漏えい疑いは緊急失効の判断を優先。旧secretの再利用に頼らない。

• 証跡で閉じる

  常駐アプリだけでなくバッチも確認。旧資格情報の停止結果と未確認の担当・期限を残す。

計画更新と漏えい対応は同じ順番にしない

OWASPの失効指針は、不要または侵害の可能性があるsecretの失効を求めています。次は編集部の判断整理です。停止影響と継続リスクを責任者へ同時に伝え、完全な証跡収集を封じ込めの前提にしません。

secretの更新・削除と、すでに発行されたaccess token、refresh token、アプリ独自セッションの失効は別です。全部が同時に無効になるとは仮定せず、対象プロバイダーの失効仕様を調べます。露出がある場合はGitHub secret leak対応チェックリストの失効・影響確認も使い、実際の発行元と利用サービスに読み替えてください。

---

読者別の影響：誰が何を見るべきか

クライアントシークレットは、ログイン画面の裏側、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を使うべきだと説明しています。

---

まず確認すること：OIDC/OAuth secret更新チェックリスト

計画更新では、削除前に次の項目を台帳化します。漏えい疑いは、情報がそろうまで旧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を無効化・削除する手順になっています。

Googleの「無効化後に再有効化できる」という通常更新の回復策を、他の製品や漏えい済みsecretに一般化しないでください。Entraの案内は新Key IDの検証後に旧資格情報を削除する流れであり、同一の無効化ボタンがある前提ではありません。両製品の具体的な操作は上記の公式手順で確認します。

Microsoft EntraとGoogle：ID・値・管理元の違い

次は2026年10月25日にMicrosoftの資格情報追加とGoogleのOAuthクライアント管理を照合した整理です。製品の画面上のIDと秘密値を混同しないでください。

Entraの資格情報追加資料は、本番では証明書またはフェデレーション資格情報を使う方向を示しています。これは障害中に無承認で認証方式を変更する指示ではなく、通常変更での移行検討です。回復用の広いsecretを新しく配るのではなく、所有者・利用経路・権限を先に確認します。

新secretへの移行完了を何で確認するか

本番Webのログインが1回成功しても、夜間バッチ、別リージョン、待機系、ワーカーが更新済みとは限りません。利用経路ごとに設定の版と資格情報の識別子を照合し、新しいトークン取得を伴う処理を確認します。観測できない経路は担当・確認期限を付け、確認済みと混ぜません。ログへsecret値やトークンを追加出力して確認する方法は取りません。

更新したのに失敗する・一部だけ動く場合の切り分け

次の表は編集部による確認観点で、エラーメッセージから原因を一意に断定するものではありません。漏えい疑いでは、この調査が終わるまで緊急失効を待つ運用にしません。

Entraの期限更新の公式手順は、新資格情報のKey IDとサインインログを照合してから旧資格情報を削除する流れです。取得できない根拠は、その理由と担当・確認期限を更新記録へ残します。

値を含めない更新記録テンプレート

承認済みの社内記録へ転記します。次は独自の型で、secret値の入力欄は設けません。

変更ID / 計画更新・期限切れ・漏えい疑い:
プロバイダー / アプリ・client ID / 環境 / 所有者:
旧・新credential IDまたは管理用識別子 / 有効期限:
保管先の参照名 / 設定版 / 反映先（Web・バッチ・待機系）:
経路ごとの新規トークン取得の確認時刻・根拠:
旧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日・60日は編集部の計画例であり、製品の保証期間や標準期限ではありません。Microsoftの期限更新レコメンデーションは30日以内を対象とするため、通知の有無だけで自社の更新期限を判断しないでください。

優先度	状況	初動判断
高	期限切れまで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を「戻し用」に残す・再有効化する判断はしません。安全な新資格情報での復旧と、必要な停止・制限を責任者と判断します。

「環境変数に入れているから安全」

環境変数は便利ですが、ログ出力、クラッシュダンプ、管理画面、CI/CD設定、権限の広い閲覧者から見える場合があります。専用のsecret manager、アクセス制御、監査ログ、ローテーションを合わせて考えます。

「SPAにclient secretを入れればセキュリティが上がる」

SPAやモバイルアプリはpublic clientであり、配布されたコードや端末上の値を安全に秘匿できません。PKCEやBFF、サーバー側トークン交換を検討します。

「PKCEを使えばclient secretは不要な場面でも全て安全」

PKCEはpublic clientの認可コード横取りリスクを下げる仕組みですが、すべての認可・認証リスクを解決するものではありません。redirect URI、state、nonce、token保存、scope、セッション管理も確認します。

---

関連用語・関連ページ

アプリの種類はPublic ClientとConfidential Clientで整理できます。共有secretから公開鍵方式へ移行を検討する場合は、private_key_jwtの鍵管理と検証条件も確認してください。各用語ページから、その用語だけのシナリオ2問へ進めます。

目的	ページ
用語を確認する	OAuth 2.0、OpenID Connect、JWT、Access Token、Refresh Token
secret管理を確認する	Secrets Management、Secret Scanning、Workload Identity
方式の違いを整理する	OAuthとOIDCの違い、SAMLとOIDCの違い、認証と認可の違い
実務チェックへ進む	GitHub secret leak対応チェックリスト、開発ツール・OSSサプライチェーン確認チェックリスト、SaaS権限棚卸しチェックリスト
関連記事を読む	GitHub Secret Scanningアラート初動対応、OAuth同意フィッシング、SAML証明書・SSO証明書の期限切れ対応
演習で確認する	GitHub secret leak 初動ミニCTF、認証と認可のミニCTF、クイズで用語を復習する

---

公式情報・参考情報

2026年10月25日の改訂ではGoogleとMicrosoftの管理・更新資料を再確認しました。その他の標準・保管原則の資料と、編集部が提案する確認表・記録様式を分けています。実テナントでの変更・失効試験を示すものではありません。

• 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対応チェックリストを発行元に読み替えて使ってください。「あとで読む」に保存すると進捗ページから再開できます。保存するのはページの参照であり、secret値や社内の作業記録をこのサイトへ入力する必要はありません。