ベスト プラクティス

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

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 Developers Console を使用して、利用規約に明示的に同意し、OAuth クライアントを構成して、OAuth の確認の準備を行う必要があります。

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

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

OAuth 2.0 クライアントを定期的に監査し、アプリで不要になったものや廃止されたものは積極的に削除してください。未使用のクライアントを構成したままにしておくと、クライアント認証情報が漏洩した場合にクライアントが不正使用される可能性があるため、セキュリティ リスクが生じます。

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

自動削除を待つのではなく、未使用のクライアントを積極的に削除することが効果的な手法です。これにより、アプリの攻撃対象領域が最小限に抑えられ、セキュリティが強化されます。