認証情報を保護する

このガイドでは、アプリケーションとユーザーの認証情報を安全に保つ方法について説明します。

OAuth アプリの確認を完了する

Google Ads API の OAuth 2.0 スコープは制限付きスコープに分類されます。つまり、アプリケーションを本番環境に移行する前に、OAuth アプリケーションの確認プロセスを完了する必要があります。詳しくは、Google Identity のドキュメントヘルプセンターの記事をご覧ください。

アプリケーションの認証情報を保護する

アプリケーションの OAuth 2.0 クライアント ID とクライアント シークレットを保護する必要があります。これらの認証情報は、ユーザーと Google がアプリケーションを識別するのに役立つため、慎重に扱う必要があります。これらのアプリケーション認証情報はパスワードと同様に扱う必要があります。公開フォーラムへの投稿、これらの認証情報を含む構成ファイルをメールの添付ファイルで送信する、認証情報をハードコードする、コード リポジトリにコミットするなど、安全でないメカニズムを使用して共有しないでください。可能であれば、Google Cloud Secret ManagerAWS Secret Manager などのシークレット マネージャーを使用することをおすすめします。

OAuth 2.0 クライアント シークレットが漏洩した場合は、リセットできます。デベロッパー トークンはリセットすることもできます。

開発者トークンを保護する

デベロッパー トークンを使用すると、アカウントに対して API 呼び出しを行うことができますが、呼び出しに使用できるアカウントに制限はありません。その結果、不正使用されたデベロッパー トークンが他者に使用され、その通話がお客様のアプリケーションに帰属する可能性があります。このシナリオを回避するには、次の予防策を講じます。

  • デベロッパー トークンはパスワードのように扱います。公開フォーラムへの投稿や、デベロッパー トークンを含む構成ファイルをメールの添付ファイルとして送信するなど、安全でないメカニズムを使用して共有しないでください。可能であれば、Google Cloud Secret ManagerAWS Secret Manager などのシークレット マネージャーを使用することをおすすめします。

  • デベロッパー トークンが漏洩した場合は、リセットする必要があります。

    • Google 広告 API の申請時に使用した Google 広告 MCC アカウントにログインします。
    • [ツールと設定] > [API Center] に移動します。
    • [デベロッパー トークン] の横にあるプルダウン矢印をクリックします。
    • [トークンをリセット] リンクをクリックします。古いデベロッパー トークンは直ちに使用できなくなります。
    • 新しいデベロッパー トークンを使用するように、アプリケーションのプロダクション構成を更新します。

サービス アカウントを保護する

サービス アカウントが Google Ads API で正しく動作するには、ドメイン全体のユーザーの権限借用が必要です。また、ドメイン全体のユーザーの権限借用を設定するには、Google Workspace のお客様である必要があります。このような理由から、Google Ads API 呼び出しを行う際にサービス アカウントを使用することはおすすめしません。ただし、サービス アカウントを使用する場合は、次のように保護する必要があります。

ユーザー トークンを保護する

アプリが複数のユーザーを承認する場合は、ユーザーの更新トークンとアクセス トークンを保護するための追加の手順を行う必要があります。トークンを安全に保存し、平文で送信しないでください。プラットフォームに適した安全なストレージ システムを使用します。

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

アプリが認可の一部として OAuth 2.0 更新トークンをリクエストする場合は、その無効化または有効期限切れも処理する必要があります。更新トークンはさまざまな理由で無効になる可能性があります。アプリケーションは、次のログイン セッションでユーザーを再認証するか、必要に応じてデータをクリーンアップすることで、適切に対応する必要があります。cron ジョブなどのオフライン ジョブは、失敗したリクエストを継続するのではなく、更新トークンの有効期限が切れたアカウントを検出して記録する必要があります。API サーバーの安定性を維持するため、一定期間にわたってエラーを大量に生成するアプリは、Google によってスロットリングされることがあります。

複数のスコープの同意を管理する

アプリが複数の OAuth 2.0 スコープの認可をリクエストした場合、ユーザーはリクエストされたすべての OAuth スコープを許可しない可能性があります。アプリは、関連する機能を無効にして、スコープの拒否を処理する必要があります。ユーザーがスコープを必要とする特定の機能を使用する意向を明確に示した後にのみ、ユーザーに再度プロンプトを表示できます。このような場合は、増分認可を使用して適切な OAuth スコープをリクエストします。

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