Microsoft EntraのAADSTS7000222が出たら、エラー説明と対象app IDを確認し、期限切れのClient Secretをどの処理が使っているかを特定します。新しいsecretを作っただけでは、その値が実行中のアプリへ届いたことも、新しいtokenが取得できたことも確認できません。
本稿はClient Secretを使う既存連携の障害切り分けと更新確認を扱います。App registrationが見つからないエラーやredirect URIの不一致とは分けます。以下の運用表は架空例であり、Microsoft Entra上で資格情報を作成・更新・実測した結果ではありません。
目次
エラー説明と対象アプリを先に固定する
Microsoftのエラーに関する公式資料（新しいタブで開く）は、AADSTS7000222を期限切れsecret、AADSTS7000215を無効なsecretの例として説明しています。この資料のAKS固有の更新コマンドは、他の連携へ流用しません。コードだけで作業を始めず、実際のerror description、時刻、対象app IDを確認します。
表は横にスクロールできます
| 観測した内容 | 確認する対象 | 直ちに決めないこと |
|---|---|---|
| 7000222と期限切れの説明 | 対象appのsecret期限と利用先 | すべてのappのsecret更新 |
| 7000215など別コード | 読み込んだ値・対象app・設定経路 | 期限だけが原因 |
| token取得後のAPI拒否 | API権限・resource側条件 | secret更新で権限も解決 |
appの表示名は似たものが存在します。アプリが実際に読むApplication (client) IDとTenant IDを、対象App registrationと照合します。secretの値を確認票へ貼る代わりに、設定の参照元とcredentialの管理上の識別子を記録します。
作成先と利用先を一枚の表で結ぶ
たとえば同じ連携にWebプロセスと夜間workerがあれば、片方だけ更新しても障害が続く場合があります。これは一般的な確認例であり、すべてのアプリが複数consumerを持つという意味ではありません。
表は横にスクロールできます
| 利用先の架空例 | 設定の参照元 | 更新後に確認する実行 |
|---|---|---|
| Webアプリ | 承認済みsecret storeの参照 | 新しいtoken取得を行う要求 |
| 夜間worker | worker用の設定参照 | 次の対象ジョブ |
| 検証環境 | 開発環境専用の参照 | 検証用の最小読取 |
設定ファイル、環境変数、secret store、デプロイ時の値など、複数の経路がある場合は採用される設定を調べます。画面で保存値を更新したことと、既存プロセスが再読込したことは別です。反映に再起動や再デプロイが必要かは利用アプリの仕組みに従って判断します。
新しい値を安全な保存先へ渡す
既存の方式を継続する必要がある場合、対象App registrationのCertificates & secretsで新しいsecretを作成し、Valueを承認された保存先へ渡す流れになります。公式資料によれば値は作成時だけ表示され、後から再表示できません。Secret IDなどの管理用識別子を、アプリへ渡すsecretの実値と取り違えないようにします。
- appと環境、更新担当、consumer一覧を確定する。
- 組織の方針に沿う資格情報を対象appへ追加する。
- 値を承認済みの保存経路へ登録し、consumer側の参照を更新する。
- 設定反映の方法を確認し、新しい認証要求で検証する。
- 利用先の確認後、期限切れの旧資格情報と古い参照を整理する。
secretをソースコード、チャット、調査ログへ転記しません。値を失った場合は、画面上の識別子から復元しようとせず、新しい資格情報を用意する手順を担当者と確認します。
Microsoft.Identity.Webは複数credentialを順に試す構成を説明していますが、すべてのSDKに同じ機能があるとは限りません。また、すでに期限切れの旧secretは、認証に成功するrollback先にはなりません。利用ライブラリの動作と、利用可能な復旧経路を分けて確認します。
キャッシュ済みaccess tokenで完了判定しない
更新後のAPI呼び出しが成功しても、以前取得したaccess tokenを使っていれば、新しいsecretが正しく読まれた証拠にはなりません。新しいtoken取得が発生したかを秘密値なしのログで確認し、その後に必要最小限のAPI操作を確認します。
表は横にスクロールできます
| 確認結果 | 分かること | まだ分からないこと |
|---|---|---|
| 設定保存が成功 | 管理側の値を更新した | 実行側への反映 |
| 新しいtoken取得が成功 | 認証要求が受け付けられた | 全resourceの操作権限 |
| 最小API読取が成功 | その操作の認証・認可が通った | 他consumerの反映 |
| 対象consumerを確認 | 更新対象の確認範囲が揃った | 未把握の利用先の有無 |
APIが403を返す場合、原因がsecretとは限りません。新しいtoken取得の成否を先に分け、必要なAPI権限やresource側の設定へ調査を進めます。障害対応のために無関係な管理者権限を追加しないようにします。
再発防止は期限と所有者を残す
更新記録には、app、環境、credentialの管理用識別子、期限、所有者、更新したconsumer、token取得とAPI確認の結果を残します。secretの実値は含めません。旧secretを整理した時刻も残せば、後から古い参照が見つかった場合に照合できます。
Microsoftはproduction向けに証明書やmanaged identity、federated identityなどのより強い方式を案内しています。今回の期限切れ復旧と方式移行は別の変更として扱い、障害中に無検証で認証方式を切り替えません。現在の方式を続ける期間があるなら、期限前に担当者が更新を実施できる運用を決めます。