ベスト プラクティス

このページでは、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）プロトコルを使用することを強くおすすめします。

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

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

段階的な認可を使用する

アプリケーションで機能が必要になったときに、適切な 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 コンソールを使用して、利用規約に明示的に同意し、OAuth クライアントを構成して、OAuth 認証の準備を行う必要があります。

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

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

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

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

推奨されるベスト プラクティスは、自動削除を待つのではなく、使用されていないクライアントを事前に削除することです。このプラクティスにより、アプリケーションの攻撃対象領域が最小限に抑えられ、セキュリティ対策が徹底されます。