このページでは、OAuth 2.0 との統合に関する一般的なベスト プラクティスについて説明します。アプリケーションの種類と開発プラットフォームに固有のガイダンスに加えて、以下のベスト プラクティスを検討してください。アプリを本番環境に移行するためのアドバイスと Google の OAuth 2.0 ポリシーもご覧ください。
クライアント認証情報を安全に処理する
OAuth クライアント認証情報はアプリの ID を識別するものであり、慎重に扱う必要があります。これらの認証情報は、Google Cloud Secret Manager などのシークレット マネージャーを使用して、安全なストレージにのみ保存してください。認証情報をハードコードしたり、コード リポジトリに commit したり、一般公開したりしないでください。
ユーザートークンを安全に処理する
ユーザートークンには、アプリケーションで使用される更新トークンとアクセス トークンの両方が含まれます。トークンは保存時に安全に保存し、書式なしテキストで送信しないでください。Android の Keystore、iOS と macOS の Keychain Services、Windows の Credential Locker など、プラットフォームに適した安全なストレージ システムを使用します。
不要になったトークンはすぐに取り消し、システムから完全に削除します。
また、プラットフォームに関する次のベスト プラクティスも検討してください。
- 多くのユーザーのトークンを保存するサーバーサイド アプリケーションの場合は、保存時にトークンを暗号化し、データストアがインターネットに公開されないようにします。
- デスクトップ アプリの場合は、Proof Key for Code Exchange（PKCE）プロトコルを使用して、アクセス トークンと交換できる認証コードを取得することを強くおすすめします。
DPoP で送信者を制限するトークン
トークンの盗難やリプレイ攻撃からアプリケーションを保護するには、DPoP（Demonstrating Proof-of-Possession）を使用してトークンを送信者に制限することを検討してください。標準の署名なしトークンは、それを傍受した任意の当事者が使用できますが、DPoP トークンは、クライアントによって生成され保持される一意の鍵ペアに暗号的にバインドされます。
DPoP を使用する場合、クライアントはトークンをリクエストまたは更新トークンを更新するときに、トークン エンドポイントに証明（署名付き JSON ウェブトークン）を提示します。この証明は、クライアントがトークンにバインドされた公開鍵に対応する秘密鍵を所有していることを示します。DPoP にバインドされた更新トークンが漏洩した場合、攻撃者はその秘密鍵なしでリプレイすることはできません。
DPoP は PKCE と連携して、包括的な保護を提供します。
- PKCE は、初期リダイレクト フロー中に認証コードを保護します。
- DPoP は、有効期間の長い更新トークンを保護し、トークンが侵害された場合のリプレイ攻撃を防ぎます。
アプリケーションが次の条件に該当する場合は、DPoP を採用することを強くおすすめします。
- インストール済みアプリケーションまたはデスクトップ アプリケーション（または Backend-for-Frontend サーバーとペアになっているシングルページ アプリケーション）として動作します。この場合、更新トークンが引き出される可能性が高くなります。
- トークン漏洩の影響が大きい、機密性の高いデータや価値の高い API にアクセスする。
- 送信者制限トークンを義務付ける厳格なコンプライアンス基準またはセキュリティ基準を満たす必要がある。
DPoP 署名を作成して DPoP バインド トークンをリクエストする詳しい手順については、DPoP 導入ガイドをご覧ください。
state パラメータを使用する
OAuth 2.0 レスポンスを処理する前に、Google から受信した state が、認可リクエストで送信した state と一致することを確認します。state パラメータは、アプリケーションによって生成される、推測不可能な一意の値にする必要があります。
state パラメータを使用すると、悪意のあるスクリプトではなくユーザーがリクエストを行っていることを確認でき、クロスサイト リクエスト フォージェリ（CSRF）攻撃のリスクを軽減できます。
更新トークンの取り消しと有効期限を処理する
アプリがオフライン アクセス用の更新トークンをリクエストしている場合は、その無効化または有効期限も処理する必要があります。トークンはさまざまな理由で無効になる可能性があります。たとえば、有効期限が切れた場合や、ユーザーまたは自動プロセスによってアプリのアクセス権が取り消された場合などです。この場合、次回のログイン時にユーザーにプロンプトを表示したり、データをクリーンアップしたりするなど、アプリケーションがどのように対応すべきかを慎重に検討してください。トークンの取り消しに関する通知を受け取るには、クロスアカウント保護機能サービスと統合します。
増分認可を使用する
増分認証を使用して、アプリケーションで機能が必要になったときに適切な OAuth スコープをリクエストします。
アプリのコア機能に不可欠な場合を除き、ユーザーが最初に認証するときにデータへのアクセスをリクエストしないでください。代わりに、可能な限り小さく、最も制限されたスコープを選択するという原則に従って、タスクに必要な特定のスコープのみをリクエストします。
アプリがアクセスをリクエストしている理由と、データがどのように使用されるかをユーザーが理解できるように、常に状況に合わせてスコープをリクエストしてください。
たとえば、アプリケーションは次のモデルに従うことができます。
- ユーザーがアプリで認証を行う
- 追加のスコープはリクエストされません。アプリは、追加のデータやアクセスを必要としない機能をユーザーが探索して使用できるようにする基本機能を提供します。
- ユーザーが、追加データへのアクセスを必要とする機能を選択する
- アプリケーションは、この機能に必要な特定の OAuth スコープの認可リクエストを行います。この機能で複数のスコープが必要な場合は、複数のスコープに関するベスト プラクティスに沿って対応してください。
- ユーザーがリクエストを拒否した場合、アプリはその機能を無効にし、再度アクセスをリクエストするための追加のコンテキストをユーザーに提供します。
複数のスコープに対する同意を処理する
複数のスコープを一度にリクエストすると、ユーザーがリクエストされたすべての OAuth スコープを付与しない可能性があります。アプリは、関連する機能を無効にすることで、スコープの拒否を処理する必要があります。
アプリの基本機能で複数のスコープが必要な場合は、同意を求める前にユーザーに説明します。
ユーザーがスコープを必要とする特定の機能を使用する意向を明確に示した場合にのみ、ユーザーに再度プロンプトを表示できます。アプリは、OAuth スコープをリクエストする前に、関連するコンテキストと理由をユーザーに提供する必要があります。
アプリが一度にリクエストするスコープの数は最小限に抑える必要があります。代わりに、増分認可を利用して、機能のコンテキストでスコープをリクエストします。
安全なブラウザを使用する
ウェブでは、OAuth 2.0 認可リクエストは、フル機能のウェブブラウザからのみ行う必要があります。 他のプラットフォームでは、適切な OAuth クライアント タイプを選択し、プラットフォームに適した方法で OAuth を統合してください。モバイル プラットフォームの WebView（Android の WebView や iOS の WKWebView など）を含む、埋め込みブラウジング環境を介してリクエストをリダイレクトしないでください。代わりに、プラットフォームに推奨される OAuth ライブラリまたは Google ログインを使用してください。
OAuth クライアントの手動作成と構成
不正行為を防止するため、OAuth クライアントをプログラムで作成または変更することはできません。Google Cloud コンソールを使用して、利用規約に明示的に同意し、OAuth クライアントを構成して、OAuth 検証の準備を行う必要があります。
自動化されたワークフローの場合は、代わりにサービス アカウントの使用を検討してください。
未使用の OAuth クライアントを削除する
OAuth 2.0 クライアントを定期的に監査し、アプリケーションで不要になったクライアントや、古くなったクライアントを事前に削除します。未使用のクライアントを構成したままにすると、クライアント認証情報が不正使用された場合にクライアントが悪用される可能性があるため、セキュリティ リスクが生じます。
未使用のクライアントによるリスクをさらに軽減するため、6 か月間使用されていない OAuth 2.0 クライアントは 自動的に削除されます。
推奨されるベスト プラクティスは、自動削除を待つのではなく、未使用のクライアントを事前に削除することです。この方法により、アプリケーションの攻撃対象領域が最小限に抑えられ、適切なセキュリティ対策が確保されます。