Google OAuthアプリがTestingで使えない場合は、認可画面に入る前の利用制限と、一度同意した後の期限切れを分けます。test userへ追加すればすべてのOAuth errorが直るわけではありません。実際のclient、所属project、利用account、要求scope、errorの発生段階を一組で確認します。
本稿はGoogle Auth PlatformのTestingと利用対象の診断です。test user追加、公開状態変更、再認証、権限変更、API要求は実施していません。以下のaccountや時系列は架空例で、実ユーザーで認証成功を測定したものではありません。
目次
最初の認可と、その後の更新失敗を分ける
認可要求で使われたclient_idと、管理画面で開くprojectの対応を確認します。開発用と本番用のclientが同名なら、名前だけで選びません。Googleのaccount切替で、予定と違うaccountを使っていないかも見ます。
表は横にスクロールできます
| 失敗する段階 | 最初の確認 | この時点の誤った対応 |
|---|---|---|
| 認可入口でaccess blocked | user type・公開状態・account | refresh tokenを消す |
| callback mismatch | 要求URIとclient設定 | test userだけ増やす |
| 一週間ほど後の更新 | 発行時状態・scope・refresh error | 全員の同意を再取得 |
| API操作だけ403 | scope・組織policy・resource権限 | 公開状態だけ変更 |
error名と画面の説明を、安全な範囲で残します。認可URL全体にはcodeやstateなどを含むことがあるため、ticketへそのまま貼りません。必要なclient識別子、発生段階、時刻、非秘密の条件で照合します。
InternalとExternal、Testingを別の軸で読む
GoogleのApp Audience資料（新しいタブで開く）で、User TypeとPublishing statusを確認します。Internalは所属organization内の対象ユーザーに限る設定で、外部accountにはorg_internalのerrorが出る場合があります。Externalだから即すべてのユーザーが全scopeを認可できる、という意味ではありません。
Testingの通常の対象は、登録されたtest userです。利用者が一覧にあるか、別名や別accountと取り違えていないかを確認します。資料はtest userの上限も案内しているため、追加と削除で枠が自由に戻ると推測せず、現在のprojectの表示と公式条件を確認します。
名前・メール・プロフィール等の限定scopeやSign in with Googleだけの場合には、Testingの通常条件に例外があります。ファイルやmail操作など別のscopeも要求しているなら、その例外を適用できると決めません。画面で設定した候補scopeだけでなく、実際のauthorize要求を確認します。
test user登録以外の制限を確認する
登録済みでも、Google Workspaceの管理policy、利用serviceの可用性、Advanced Protection等のaccount条件で認可できない場合があります。test user一覧へ何度も入れ直す前に、errorの記載と利用accountの管理者設定を照合します。個人accountと組織accountを、同じ条件として比較しないようにします。
表は横にスクロールできます
| 条件 | 確認する証拠 | 次の確認先 |
|---|---|---|
| projectの取り違え | 実client_idとproject | アプリ管理者 |
| Internalの対象外 | organizationとaccount | project管理者 |
| Testingの対象外 | 実accountと一覧・scope | OAuth設定管理者 |
| 組織policyの拒否 | errorと必要service | Workspace管理者 |
| 別のOAuth不一致 | callback・要求条件 | 認証実装担当 |
許可されないaccountを別のaccountへ切り替えて業務データへ入る、といった回避を復旧手順にしません。必要な利用者・service・scopeが組織方針に合うかを、管理者が判断できる資料にします。
7日の条件は、同意時点とscopeで確認する
OAuthのrefresh token説明（新しいタブで開く）は、ExternalかつTestingで発行されるrefresh tokenの7日条件と、基本プロフィールscopeだけの場合の例外を案内しています。Audience資料もtest userの認可期限を説明しています。access token一個の寿命と、同意・refresh tokenの条件を混ぜません。
最後に成功した定期処理と最初の失敗の間には観測の空白があります。「月曜に失敗した」だけを正確な失効時刻や発行日としません。発行時の状態、同意日、要求scope、更新errorを照合します。invalid_grantはほかの失効理由でも起きるため、一週間という印象だけで原因を確定しないようにします。
再認証が必要なら、対象の利用者、正しいclient、必要scope、安全な保存先を先に確定します。他ユーザーのtokenを消さず、応答に新しいrefresh tokenがない場合も保存値を空へ上書きしません。復旧確認は、同意完了と、実際の更新・必要なAPI操作を分けます。
Productionへの変更を障害回避のボタンにしない
In productionへの切替と、sensitive/restricted scope等のverificationは別の条件です。公開状態を替えただけで、すべての警告・利用上限・組織policyが解消すると考えません。実際に必要なユーザー範囲、scope、verification要件を確認して公開運用を設計します。
診断では元の公開状態、対象account、scope、error、確認結果を保存し、必要な設定差分だけを扱います。変更で対象ユーザーやデータアクセスが広がる場合は、その判断を明示します。完了とは警告が消えたことだけでなく、想定した利用者が必要な条件で認可でき、期限切れ後も適切に再認証へ戻れることです。