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