このガイドでは、アプリケーションとユーザーの認証情報を保護する方法について説明します。
OAuth アプリの確認を完了する
Google Ads API の OAuth 2.0 スコープは 制限付きスコープに分類されます。つまり、アプリケーションを本番環境に移行する前に、OAuth アプリの確認プロセスを 完了する必要があります。詳しくは、 Google Identity のドキュメント、未検証アプリに関する ヘルプセンター記事、およびOAuth 同意画面の設定に関するドキュメントをご覧ください。
アプリケーションの認証情報を保護する
アプリケーションの OAuth 2.0 クライアント ID とクライアント シークレットを保護する必要があります。 これらの認証情報は、ユーザーと Google がアプリケーションを識別するのに役立つため、慎重に扱う必要があります。これらのアプリケーション認証情報はパスワードと同様に扱う必要があります。公開フォーラムへの投稿、これらの認証情報を含む構成ファイルをメールの添付ファイルとして送信する、認証情報をハードコードする、コード リポジトリにコミットするなど、安全でないメカニズムを使用して共有しないでください。可能な場合は、Google Cloud Secret Manager や AWS Secret Manager などのシークレット マネージャーを使用することをおすすめします。
OAuth 2.0 クライアント シークレットが漏洩した場合は、 リセットできます。
サービス アカウントを保護する
サービス アカウントを使用する場合は、次のように保護します。
サービス アカウント キーと JSON ファイルをパスワードとして扱います。可能な場合は、 Google Cloud Secret Manager や AWS Secret Manager などのシークレット マネージャーを使用して保護します。
Google Cloud の追加のベスト プラクティスに沿って、サービス アカウントを保護、管理します。
ユーザー トークンを保護する
アプリが複数のユーザーを承認する場合は、ユーザーの更新トークンとアクセス トークンを保護するための追加の手順を行う必要があります。トークンは安全に保存し、 平文で送信しないでください。プラットフォームに適した安全なストレージ システムを使用してください。
更新トークンの取り消しと有効期限切れを処理する
アプリが承認の一部として OAuth 2.0 更新トークンをリクエストする場合は、無効化または有効期限切れも処理する必要があります。更新トークンは さまざまな理由で無効になる可能性があります。アプリは、次のログイン セッションでユーザーを再認証するか、必要に応じてデータをクリーンアップすることで、適切に対応する必要があります。cron ジョブなどのオフライン ジョブでは、リクエストの失敗を繰り返すのではなく、更新トークンの有効期限が切れたアカウントを検出して記録する必要があります。Google は、API サーバーの安定性を維持するため、一定期間にわたって大量のエラーを生成するアプリケーションをスロットリングする場合があります。
複数のスコープの同意を管理する
アプリが複数の OAuth 2.0 スコープの承認をリクエストした場合、ユーザーがリクエストしたすべての OAuth スコープを付与しない可能性があります。アプリは、関連する機能を無効にすることで、スコープの拒否を処理する必要があります。ユーザーがスコープを必要とする特定の機能を使用する意思を明確に示した後にのみ、ユーザーに再度プロンプトを表示できます。このような場合は、段階的な承認を使用して 適切な OAuth スコープをリクエストします。
アプリの基本機能に複数のスコープが必要な場合は、同意を求める前に、この要件をユーザーに説明してください。