このページでは、OAuth 2.0 と統合するための一般的なベスト プラクティスについて説明します。アプリケーションや開発プラットフォームの種類に応じた具体的なガイダンスに加えて、以下のベスト プラクティスを検討してください。また、アプリを本番環境に対応させるためのアドバイスと Google の OAuth 2.0 ポリシーもご覧ください。
クライアント認証情報を安全に処理する
OAuth クライアント認証情報はアプリの ID を識別するものであり、慎重に取り扱う必要があります。これらの認証情報は、Google Cloud Secret Manager などのシークレット マネージャーを使用するなどして、安全なストレージにのみ保存してください。認証情報をハードコードしたり、コード リポジトリに commit したり、一般公開したりしないでください。
ユーザー トークンを安全に処理する
ユーザー トークンには、アプリケーションで使用される更新トークンとアクセス トークンの両方が含まれます。トークンは保存時に安全に保存し、書式なしテキストで送信しないでください。Android のキーストア、iOS と macOS のキーチェーン サービス、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 Developers Console を使用して明示的に利用規約を確認し、OAuth クライアントを構成して、OAuth 検証の準備を行う必要があります。
自動化されたワークフローの場合は、代わりにサービス アカウントの使用を検討してください。