ベスト プラクティス

クライアント認証情報を安全に処理する

OAuth クライアント認証情報はアプリの ID を識別するものであるため、慎重に扱う必要があります。これらの認証情報は、Google Cloud Secret Manager などのシークレット マネージャーを使用して、安全なストレージにのみ保存します。認証情報をハードコードしたり、コード リポジトリに commit したり、一般公開したりしないでください。

ユーザー トークンを安全に処理する

ユーザー トークンには、アプリケーションで使用される更新トークンとアクセス トークンの両方が含まれます。トークンは保存中に安全に保存し、平文で送信しないでください。Android の Keystore、iOS と macOS の Keychain Services、Windows の Credential Locker など、プラットフォームに適した安全なストレージ システムを使用します。

不要になったらすぐにトークンを無効し、システムから完全に削除します。

また、プラットフォームに応じて次のベスト プラクティスも検討してください。

• 多くのユーザーのトークンを保存するサーバーサイド アプリケーションの場合は、保存時にトークンを暗号化し、データストアがインターネットから一般公開されないようにします。
• ネイティブ デスクトップ アプリの場合は、アクセス トークンと交換できる認証コードを取得するために、Proof Key for Code Exchange（PKCE）プロトコルを使用することを強くおすすめします。

更新トークンの取り消しと有効期限切れを処理する

アプリがオフライン アクセス用の更新トークンをリクエストしている場合は、その無効化または有効期限切れも処理する必要があります。トークンは、期限切れになった場合や、ユーザーまたは自動プロセスによってアプリのアクセス権が取り消された場合など、さまざまな理由で無効になることがあります。この場合は、次回のログイン時にユーザーにプロンプトを表示する、データをクリーンアップするなど、アプリケーションがどのように応答するかを慎重に検討してください。トークンの取り消しを通知するには、クロスアカウント保護サービスを統合します。

増分認可を使用する

増分認可を使用して、アプリで機能が必要になったときに適切な OAuth スコープをリクエストします。

アプリのコア機能に不可欠な場合を除き、ユーザーが初めて認証するときにデータへのアクセスをリクエストしないでください。代わりに、可能な限り最も小さく制限されたスコープを選択するという原則に従い、タスクに必要な特定のスコープのみをリクエストします。

スコープは常にコンテキスト内でリクエストし、アプリがアクセスをリクエストする理由とデータの使用方法をユーザーが理解できるようにしてください。

たとえば、アプリケーションは次のモデルに従う場合があります。

1. ユーザーがアプリで認証します。
   1. 追加のスコープはリクエストされません。アプリは、追加のデータやアクセスを必要としない機能をユーザーが探索して使用できるようにする基本機能を提供します。
2. ユーザーが追加データへのアクセスが必要な機能を選択した場合
   1. アプリは、この機能に必要な特定の OAuth スコープの認可リクエストを行います。この機能に複数のスコープを必要とする場合は、以下のベスト プラクティスに沿って対応してください。
   2. ユーザーがリクエストを拒否すると、アプリは機能を無効にし、アクセスを再度リクエストするための追加のコンテキストをユーザーに提供します。

複数のスコープの同意を処理する

複数のスコープを一度にリクエストする場合、ユーザーがリクエストしたすべての OAuth スコープを付与しないことがあります。アプリは、関連する機能を無効にして、スコープの拒否を処理する必要があります。

アプリの基本機能に複数のスコーパスが必要な場合は、同意を求める前にその旨をユーザーに説明してください。

ユーザーが、そのスコープを必要とする特定の機能を使用することを明確に示した後にのみ、ユーザーに再度プロンプトを表示できます。アプリは、OAuth スコープをリクエストする前に、関連するコンテキストと正当な理由をユーザーに提示する必要があります。

アプリが一度にリクエストするスコープの数は最小限に抑える必要があります。代わりに、増分承認を使用して、機能のコンテキストでスコープをリクエストします。

安全なブラウザを使用する

ウェブでは、OAuth 2.0 認可リクエストは、フル機能のウェブブラウザからのみ行う必要があります。 他のプラットフォームでは、適切な OAuth クライアント タイプを選択し、プラットフォームに応じて OAuth を統合してください。埋め込みブラウジング環境（Android の WebView や iOS の WKWebView など、モバイル プラットフォームの WebView など）を介してリクエストをリダイレクトしないでください。代わりに、プラットフォームのネイティブ OAuth ライブラリまたは Google ログインを使用してください。

OAuth クライアントの手動作成と構成

不正使用を防ぐため、OAuth クライアントはプログラムで作成または変更できません。Google デベロッパー コンソールを使用して、利用規約を明示的に承認し、OAuth クライアントを構成して、OAuth の確認の準備を行う必要があります。

自動化されたワークフローの場合は、代わりにサービス アカウントの使用を検討してください。

未使用の OAuth クライアントを削除する

OAuth 2.0 クライアントを定期的に監査し、アプリケーションで不要になったクライアントや廃止されたクライアントを事前に削除します。未使用のクライアントを構成したままにしておくと、クライアント認証情報が侵害された場合にクライアントが不正使用される可能性があるため、セキュリティ リスクが生じる可能性があります。

未使用のクライアントによるリスクをさらに軽減するため、6 か月間使用されていない OAuth 2.0 クライアントは 自動的に削除されます。

自動削除を待たずに、使用していないクライアントを事前に削除することをおすすめします。この方法により、アプリケーションの攻撃対象領域が最小限に抑えられ、適切なセキュリティ対策が確実に実施されます。