Google OAuth 2.0 を使用するアプリケーションを開発してデプロイする際は、アプリケーションが取りうるさまざまな状態と、それらの状態が Google Workspace 管理者の制御とどのように連携するかを理解することが重要です。このページでは、OAuth アプリの公開ステータス、ユーザータイプ、確認要件の概要について説明します。
アプリケーションの種類を特定する
プロジェクトに適用されるポリシーと制御を理解するには、まず対象ユーザーを特定します。
- どこでも使用できるアプリ: これらのアプリケーションは、個々の Google アカウント所有者や外部の Google Workspace 組織内のユーザーなど、可能な限り幅広いユーザーを対象としています。これらは、Google Cloud コンソールで [外部] ユーザータイプとして構成されます。詳しくは、ユーザータイプ: 外部をご覧ください。
- Google Workspace 組織内でのみ使用されるアプリ: これらのアプリは非公開で、独自の Google Workspace ドメイン内のユーザーに限定されます。組織外のユーザーはアクセスできません。これらは、内部ユーザータイプとして構成されます。アプリケーションとそのユーザーには、組織レベルの管理ポリシーが適用されます。このポリシーは、標準の OAuth の動作をオーバーライドできます。詳しくは、ユーザーの種類: 内部をご覧ください。
Google OAuth プラットフォームの動作の比較
次の表に、公開ステータス、ユーザータイプ、確認ステータスのさまざまな構成がアプリの動作とアクセスにどのように影響するかを示します。これらの動作は、OAuth 検証ポリシーとトークンの有効期限ルールに則って制御されます。
| 公開状況 | ユーザータイプ | テストユーザーに適用可能か？ | 確認ステータス | メモ |
|---|---|---|---|---|
| なし | 内部 | いいえ | なし | 組織内のすべてのユーザーがアクセスできます。確認は不要です。同意画面にスコープが表示されないことがあります。内部専用アプリに便利です。 |
| テスト | 外部 | はい | なし | テストユーザーの許可リストに明示的に追加されたユーザーのみがアプリにアクセスできます（テストユーザーの上限は 100 人です）。例外: アプリが基本的な ID スコープ（openid、email、profile）のみをリクエストする場合、許可リストに登録されていなくても、どのユーザーでもアクセスできます。ユーザーには、標準の未確認アプリの画面ではなく、アプリがテスト中であることを示す警告 UI が表示されます。注: アプリのユーザータイプが [内部] に設定されていない限り、組織のユーザーもこれらのテスト要件の対象となります。開発とテストに役立ちます。 |
| 公開済み | 外部 | いいえ | 未確認 | すべての Google ユーザーがアクセスできます。使用しないことを強くおすすめします。アプリのブランド確認が完了していないため、同意画面にアプリの名前とロゴが表示されません。また、プライベートにかかわるスコープや制限されたスコープをリクエストするアプリでは、未確認アプリの警告（危険 UI）がユーザーに表示され、ユーザー数の上限が 100 人に設定されます。 |
| 公開済み | 外部 | いいえ | 確認済み | すべての Google ユーザーがアクセスできます。機密性の高いスコープや制限付きスコープをリクエストする一般公開アプリに必要です。ブランドとスコープが確認されると、同意画面にアプリ名、ロゴ、スコープが警告なしで表示されます。 |
Google Workspace 環境での管理者のオーバーライド
Google Workspace 管理者は、Google Cloud コンソールのアプリの設定に関係なく、OAuth アプリが組織のデータにアクセスする方法を大幅に制御できます。これらの制御は、Google Workspace 管理コンソールの [API の制御] で管理されます。
- ユニバーサル制御: Google Workspace 管理者は、内部アプリ、外部アプリ、テスト版アプリ、公開済みアプリ、確認済みアプリ、未確認アプリのいずれであっても、OAuth アプリを常にブロックして、ユーザーがアプリを承認できないようにすることができます。
- 内部アプリ: Google Workspace 組織内で暗黙的に信頼されていることが多く、特に管理者が [ドメインで所有する社内アプリを信頼する] を有効にしている場合はその傾向が強くなります。ただし、管理者は [信頼できる]、[限定]、[ブロック中] などのラベルを適用して、アクセスを微調整できます。ドメイン全体の委任（DWD）を構成して、特定のスコープに対するユーザーの同意をバイパスすることもできます。
- 外部アプリ:
- 未確認: 管理者が信頼する可能性は低く、ブロックまたは制限される可能性があります。管理者は、未確認の外部アプリをドメインの「信頼できる」アプリとしてマークできますが、一般的には推奨されません。
- 確認済み: Google の確認は信頼性を高めますが、Google Workspace 管理者は引き続きすべての権限を保持します。ステータスが「確認済み」であっても、Google Workspace 管理者の設定がオーバーライドされることはありません。管理者は、アプリを [信頼できる]（管理者が設定したスコープ制限の一部をバイパス）、[限定]（サービス制限の対象）、[ブロック中] のいずれかに設定できます。
[信頼できる] ステータスのオーバーライド: Google Workspace 管理者がアプリを [信頼できる] とマークすると、その組織の内部アプリケーションとして扱われます。このステータスは、組織のユーザーに対する特定の標準 OAuth 制限（テスト中ステータスのアプリのテストユーザーの上限 100 人、更新トークンの有効期限 7 日間など）をオーバーライドします。
つまり、Google の確認プロセスは一般的なポリシー遵守のシグナルですが、アプリが組織のデータにアクセスできるかどうかを最終的に判断するのは Google Workspace 管理者です。
次のステップ
アプリを本番環境用に準備する方法と Google Workspace 固有の考慮事項の処理について詳しくは、以下のリソースをご覧ください。