このページでは、OAuth 2.0 との統合に関する一般的なベスト プラクティスについて説明します。アプリケーションの種類と開発 プラットフォームに固有のガイダンスに加えて、これらのベスト プラクティスも考慮してください。また、 アプリを本番環境に対応させるための アドバイスと Google's 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）プロトコルを使用して、アクセス トークンと交換できる認可コードを取得することを強くおすすめします。
state パラメータを使用する
OAuth 2.0 レスポンスを処理する前に、state が
Google から受信した認可リクエストで送信した state と一致していることを確認します。
state パラメータは、アプリによって生成される一意の推測不可能な値にする必要があります。
state パラメータを使用すると、リクエストを行っているのが悪意のあるスクリプトではなくユーザーであることを確認でき、クロスサイト リクエスト フォージェリ
（CSRF）攻撃のリスクを軽減できます。
更新トークンの取り消しと有効期限切れを処理する
アプリがオフライン アクセス用の更新 トークンをリクエストしている場合は、無効化または有効期限切れも処理する必要があります。トークンが無効になる理由はさまざまです。たとえば、有効期限が切れたり、ユーザーまたは自動プロセスによってアプリのアクセス権が取り消されたりする可能性があります。この場合は、次のログイン時にユーザーに通知する、データをクリーンアップするなど、アプリがどのように対応すべきかを慎重に検討してください。トークンの取り消しに関する通知を受け取るには、クロスアカウント保護サービスと統合します。
段階的な認可を使用する
段階的な認可を使用して、アプリで機能が必要になったときに適切な OAuth スコープをリクエストします。
アプリのコア機能に不可欠な場合を除き、ユーザーが最初に認証するときにデータへのアクセス権をリクエストしないでください。タスクに必要な特定のスコープのみをリクエストし、可能な限り最小かつ最も限定的なスコープを選択するという原則に従います。
ユーザーがアプリにアクセス権をリクエストする理由とデータの使用方法を理解できるように、常にコンテキスト内でスコープをリクエストしてください。
たとえば、アプリは次のモデルに従うことができます。
- ユーザーがアプリで認証する
- 追加のスコープはリクエストされません。アプリは、追加のデータやアクセスを必要としない機能をユーザーが探索して使用できるように、基本的な機能を提供します。
- ユーザーが追加のデータへのアクセスを必要とする機能を選択する
- アプリは、この機能に必要な特定の OAuth スコープの認可リクエストを行います 。この機能に複数のスコープが必要な場合は、 以下のベスト プラクティスに従ってください。
- ユーザーがリクエストを拒否した場合、アプリはその機能を無効にし、ユーザーが再度アクセスをリクエストするための追加のコンテキストを提供します。 追加のコンテキストを提供します。
複数のスコープの同意を処理する
複数のスコープを一度にリクエストすると、ユーザーがリクエストしたすべての OAuth スコープを許可しない可能性があります。アプリは、関連する機能を無効にすることで、スコープの拒否を処理する必要があります。
アプリの基本機能に複数のスコープが必要な場合は、同意を求める前にユーザーに説明してください。 同意を求める前にユーザーに説明してください。
ユーザーがスコープを必要とする特定の機能を使用する意思を明確に示した後にのみ、再度ユーザーに確認できます。アプリは、OAuth スコープをリクエストする前に、関連するコンテキスト と正当な理由をユーザーに提供する必要があります。
アプリが一度にリクエストするスコープの数を最小限に抑える必要があります。代わりに、 段階的な認可を使用して、機能のコンテキスト内でスコープをリクエストします。
安全なブラウザを使用する
ウェブでは、OAuth 2.0 認可リクエストは、フル機能のウェブブラウザからのみ行う必要があります。 他のプラットフォームでは、 正しい OAuth クライアント タイプを選択し、 プラットフォームに応じて OAuth を統合してください。Android の WebView や iOS の WKWebView など、モバイル プラットフォームの WebView を含む、埋め込みブラウジング 環境を介してリクエストをリダイレクトしないでください。代わりに、プラットフォームのネイティブ OAuth ライブラリ または Google ログインを使用してください。
OAuth クライアントの手動作成と構成
不正使用を防ぐため、OAuth クライアントをプログラムで作成または変更することはできません。Google Developers Console を使用して、利用規約に明示的に同意し、OAuth クライアントを構成して、OAuth の確認の準備を行う必要があります。
自動ワークフローの場合は、代わりに サービス アカウントの使用を検討してください。
未使用の OAuth クライアントを削除する
OAuth 2.0 クライアントを定期的に監査し、アプリで不要になったものや廃止されたものは積極的に削除してください。未使用のクライアントを構成したままにしておくと、クライアント認証情報が漏洩した場合にクライアントが不正使用される可能性があるため、セキュリティ リスクが生じます。
未使用のクライアントによるリスクをさらに軽減するため、6 か月間アクティブでない OAuth 2.0 クライアントは自動的に削除されます。
自動削除を待つのではなく、未使用のクライアントを積極的に 削除することをおすすめします。これにより、アプリの攻撃対象領域が最小限に抑えられ、セキュリティが強化されます。