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