Skip to main content
アカウントは AdCP においてバイヤーとセラー間の請求関係を表します。セールスエージェントはアカウントを使用して料金（レートカード）、請求エンティティを決定し、異なるバイヤー間のデータアイソレーションを適用します。

​
認証

すべてのリクエストは標準の Authorization ヘッダーにベアラートークンを使用して認証する必要がある: 
Authorization: Bearer <your_token>
サーバーはこのトークンを検証し、リクエストを行っているエージェントを識別します。エージェントは1つ以上のアカウントにアクセスできます。 認証情報の取得と認証方法の詳細は Authentication を参照。

​
エージェントとアカウント

AdCP は以下を区別する:
  • エージェント: API コールを行う認証済みエンティティ（例: "pinnacle_trading_desk"）
  • アカウント: メディアバイの請求関係（例: "acme_c/o_pinnacle"）
エージェントは複数のアカウントで操作できます。例えば、エージェンシーのトレーディングデスクは複数の広告主のアカウントと自社のハウスアカウントを管理する場合があります。詳細は Accounts and Agents を参照。

​
データアイソレーション

認証は厳格なデータアイソレーションの基盤を提供します。セールスエージェントは以下のルールを適用しなければなりません (MUST):
  1. MediaBuy などのオブジェクトが作成される場合、そのリクエストで使用されたアカウントと永続的に関連付けなければなりません (MUST)。
  2. そのオブジェクトを読み取るまたは変更するその後のリクエストでは、サーバーはエージェントがそのアカウントへのアクセスを持つことを検証しなければなりません (MUST)。
  3. エージェントがアクセスを持たない場合、サーバーは権限拒否エラーを返さなければなりません (MUST)。
このモデルにより、1つのアカウントのデータが認可されていないエージェントにアクセスされないことが保証されます。アクセス権を持たないアカウントの account_id を渡すとエラーになります。

​
セキュリティ要件

​
必須セキュリティ対策

セールスエージェントの実装は以下をしなければなりません (MUST):
  • すべての認証済みリクエストでベアラートークンを検証します
  • アカウントベースのデータアイソレーションを適用します
  • すべての通信に TLS を使用します
  • セキュリティ監視のために認証失敗をログに記録します

​
推奨セキュリティ対策

セールスエージェントの実装は以下をすべきだ (SHOULD):
  • エージェントとアカウントごとにレート制限を実装します
  • トークンの有効期限とリフレッシュをサポートします
  • コンプライアンスのために監査ログを提供します
  • 高セキュリティアカウントのための IP ホワイトリストをサポートします