おすすめの方法

このページでは、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 スコープをリクエストします。

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

アプリがアクセスをリクエストする理由とデータの用途をユーザーが理解できるように、常に状況に応じてスコープをリクエストしてください。

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

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

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

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

アプリの基本機能に複数のスコープが必要な場合は、同意を求める前にユーザーに説明します。

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

アプリが一度にリクエストするスコープの数を最小限に抑える必要があります。代わりに、段階的承認を利用して、特長と機能のコンテキストに即したスコープをリクエストします。

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

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

OAuth クライアントを手動で作成して構成する

不正使用を防ぐため、OAuth クライアントをプログラムで作成または変更することはできません。Google Developers Console を使用して、利用規約を明示的に同意し、OAuth クライアントを構成して、OAuth 検証の準備を行う必要があります。

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