このページでは、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）プロトコルを使用することを強くおすすめします。
更新トークンの取り消しと期限切れを処理する
アプリがオフライン アクセス用の更新トークンをリクエストしている場合は、その無効化または有効期限切れも処理する必要があります。トークンは、期限切れになったり、ユーザーまたは自動プロセスによってアプリのアクセス権が取り消されたりするなど、さまざまな理由で無効になることがあります。この場合は、次回ログイン時にユーザーにプロンプトを表示する、データをクリーンアップするなど、アプリがどのように応答するかを慎重に検討してください。トークンの取り消しを通知するには、クロスアカウント保護サービスを統合します。
増分認可を使用する
増分認可を使用して、アプリで機能が必要になったときに適切な OAuth スコープをリクエストします。
アプリのコア機能に不可欠な場合を除き、ユーザーが初めて認証するときにデータへのアクセスをリクエストしないでください。代わりに、可能な限り最も小さく制限されたスコープを選択するという原則に従い、タスクに必要な特定のスコープのみをリクエストします。
アプリがアクセス権をリクエストする理由とデータの使用方法をユーザーが理解できるように、常にコンテキスト内でスコープをリクエストしてください。
たとえば、アプリケーションは次のモデルに従います。
- ユーザーがアプリで認証します
- 追加のスコープはリクエストされません。アプリは、追加のデータやアクセス権を必要としない機能をユーザーが探索して使用できるようにする基本機能を提供します。
- ユーザーが追加データへのアクセスが必要な機能を選択した場合
- アプリケーションは、この機能に必要な、この特定の OAuth スコープに対して認可リクエストを行います。この機能に複数のスコープを必要とする場合は、以下のベスト プラクティスに沿って対応してください。
- ユーザーがリクエストを拒否すると、アプリは機能を無効にし、ユーザーにアクセスを再度リクエストするための追加のコンテキストを提供します。
複数のスコープの同意を処理する
複数のスコープを一度にリクエストする場合、ユーザーがリクエストしたすべての OAuth スコープを付与しないことがあります。アプリでは関連する機能を無効にして、スコープの拒否を処理する必要があります。
アプリの基本機能に複数のスコーパスが必要な場合は、同意を求める前にその旨をユーザーに説明してください。
ユーザーが、そのスコープを必要とする特定の機能を使用することを明確に示した場合にのみ、ユーザーに再度プロンプトを表示できます。アプリは、OAuth スコープをリクエストする前に、関連するコンテキストと正当な理由をユーザーに提示する必要があります。
アプリが一度にリクエストするスコープの数は最小限に抑える必要があります。代わりに、増分認可を使用して、機能のコンテキストでスコープをリクエストします。
安全なブラウザを使用する
ウェブでは、OAuth 2.0 認可リクエストは、フル機能のウェブブラウザからのみ行う必要があります。 他のプラットフォームでは、適切な OAuth クライアント タイプを選択し、プラットフォームに応じて OAuth を統合してください。埋め込みブラウジング環境（Android の WebView や iOS の WKWebView など、モバイル プラットフォームの WebView など）を介してリクエストをリダイレクトしないでください。代わりに、プラットフォームのネイティブ OAuth ライブラリまたは Google ログインを使用してください。
OAuth クライアントの手動作成と構成
不正使用を防ぐため、OAuth クライアントをプログラムで作成または変更することはできません。Google デベロッパー コンソールを使用して、利用規約を明示的に承認し、OAuth クライアントを構成して、OAuth 確認の準備を行う必要があります。
自動化されたワークフローの場合は、代わりにサービス アカウントの使用を検討してください。