認証

​

認証が必要な場面

​

公開操作（認証不要）

• get_adcp_capabilities - エージェントの機能、ポートフォリオ、対応機能の取得
• list_creative_formats - 利用可能なクリエイティブ形式の閲覧
• get_products - 在庫の探索（認証なしでは結果が限定）

• 一部のカタログ（標準商品）のみ
• 価格情報や CPM の非表示
• カスタム商品なし
• 汎用的なフォーマット対応のみ

​

認証が必要な操作

• get_products (full access) - Complete catalog with pricing and custom products
• create_media_buy - Create advertising campaigns
• update_media_buy - Modify existing campaigns
• sync_creatives - Upload creative assets
• list_creatives - View your creative library
• get_media_buy_delivery - Monitor campaign performance and metrics
• provide_performance_feedback - Submit optimization signals

​

認証方式

​

静的 Authorization クレデンシャル（3.0 ベースライン）

Authorization: Bearer <token>
Authorization: Basic <base64(username:password)>

• Opaque tokens: サーバーで検証されるエージェント紐づけ文字列
• JWT tokens: クレームを埋め込んだ自己完結型トークン

​

RFC 9421 リクエスト署名（推奨。3.1+ の変更系操作で必須）

​

mTLS

​

JWT のクレーム

{
  "sub": "agent_123",
  "exp": 1706745600,
  "iat": 1706742000
}

​

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

• エージェント: API 呼び出しを行う認証済みエンティティ（トークンで識別）
• アカウント: 料率と請求を決定する課金関係

​

テナント解決

​

クレデンシャルの配置

• HTTP 上の静的クレデンシャル — RFC 6750 §2 に従う Authorization: Bearer <token>、またはセラーが HTTP Basic クレデンシャルをプロビジョニングする場合は Authorization: Basic <base64(username:password)>。
• RFC 9421 署名付きリクエスト — RFC 9421 §2 に従う Signature および Signature-Input ヘッダー。署名自体がクレデンシャルであり、ペイロード内には署名者を認証するものは何もありません。
• MCP および A2A の認証フレーミング — トランスポートの認証記述子（例: MCP の authInfo、A2A の authentication.schemes）。認証要件のディスカバリーは、該当する場合 RFC 9728 §3 の保護リソースメタデータに従います。
• 相互 TLS — 上表の mTLS 行に従うピア証明書。

​

カーブアウト

• push_notification_config.authentication.credentials（スキーマ）。これは、セラーがバイヤーの Webhook エンドポイントに折り返し呼び出す際に使用するレガシー Bearer / HMAC-SHA256 クレデンシャルです。セラーを呼び出し元として、バイヤーを受信側として認証します — インバウンドの AdCP リクエストを認証するバイヤープリンシパルのクレデンシャルとは直交します。デフォルトの 9421 Webhook プロファイルは brand.json で発見された鍵を使用し、共有シークレットを一切交換しません。レガシーブロックは AdCP 4.0 で削除される非推奨の互換スキームです。
• 帯域外で交換されるオンボーディング時のシークレット — 初回トークン発行、OAuth 動的登録レスポンス、ダッシュボード発行の API キー。これらは AdCP タスクペイロードとしてではなく、AAO 認可サーバーまたはセラーのオンボーディングフローを通過します。

​

リレーエージェント

​

プロトコル設定

{
  "auth": {
    "type": "bearer",
    "token": "<your_token>"
  }
}

• A2A — Authorization のみ。Bearer クレデンシャルの場合、Authorization: Bearer <token> を送信し、セラーのエージェントカードで bearerAuth HTTPAuthSecurityScheme を宣言します（A2A ガイド — エージェントカードを参照）。Basic クレデンシャルの場合、Authorization: Basic <base64(username:password)> を送信し、HTTP Basic を宣言します。x-adcp-auth カスタムヘッダーは A2A 面では認識されません。
• MCP — Authorization が Bearer および Basic クレデンシャルの主要ヘッダーです。x-adcp-auth は adcp 4.5.0 より前の統合向けの後方互換 Bearer エイリアスとして受け入れられます。新しい実装は両方のレッグで標準ヘッダーを使用すべきです。

​

MCP クライアントの設定

​

MCP クライアントライブラリの利用

import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';

const transport = new StreamableHTTPClientTransport(
  new URL('https://agenticadvertising.org/api/training-agent/mcp'),
  {
    requestInit: {
      headers: {
        'Authorization': 'Bearer YOUR_TOKEN_HERE'
      }
    }
  }
);

const client = new Client({ name: 'my-client', version: '1.0.0' });
await client.connect(transport);

from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

async with streamablehttp_client(
    "https://agenticadvertising.org/api/training-agent/mcp",
    headers={"Authorization": "Bearer YOUR_TOKEN_HERE"}
) as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()

​

よくある誤り: 生の HTTP ヘッダー追加

# This won't work for MCP endpoints
GET /mcp HTTP/1.1
Authorization: Bearer YOUR_TOKEN

​

認証トラブルシュート

1. MCP クライアントライブラリを使っているか確認 - 生の HTTP 呼び出しをしていないか
2. トークンの渡し方を確認 - トランスポート設定に渡しているか
3. 公開テストエージェントで試験 - カスタムエージェント前に動作確認
4. プロトコルバージョンを確認 - クライアントとサーバーの互換性を確保

​

認証情報の取得

​

アカウント開設フロー

1. Sales agent を特定: パブリッシャーの adagents.json から発見
2. 営業窓口に連絡: エージェントの営業/提携チームに問い合わせ
3. オンボーディング: 企業情報の提供、契約締結、課金設定
4. 認証情報を受領: API キーまたは OAuth クライアント資格情報を取得

​

動的クライアント登録（オプション）

POST /oauth/register
Content-Type: application/json

{
  "client_name": "Your Company Name",
  "redirect_uris": ["https://yourapp.com/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "scope": "adcp:products adcp:media_buys adcp:creatives"
}

​

アグリゲーションプラットフォーム

• 認証情報管理
• 金銭的なやり取り
• 契約手続き
• コンプライアンス監視

​

AAO プラットフォームサービスへの認証

• 認可サーバーメタデータ（RFC 8414）: https://agenticadvertising.org/.well-known/oauth-authorization-server
• 保護リソースメタデータ（RFC 9728）: /.well-known/oauth-protected-resource/api（REST API）および /.well-known/oauth-protected-resource/mcp（MCP）。どちらも https://agenticadvertising.org を認可サーバーとして列挙します。
• フロー: PKCE（S256）付き認可コード。ユーザーアイデンティティは WorkOS AuthKit 経由。トークンは署名付き JWT です。
• 動的クライアント登録（RFC 7591）: POST /register。
• サーバー間: client_credentials グラントはありません。バックエンドサービスは OAuth /token エンドポイントではなく、AAO ダッシュボードの WorkOS 組織 API キーを使用すべきです。

​

エラーレスポンス

​

保護された操作への未認証リクエスト

{
  "error": {
    "code": "AUTH_REQUIRED",
    "message": "Authentication required for this operation"
  }
}

​

無効または期限切れの認証情報

{
  "error": {
    "code": "AUTH_INVALID",
    "message": "Invalid or expired credentials"
  }
}

​

権限不足

{
  "error": {
    "code": "INSUFFICIENT_PERMISSIONS",
    "message": "Agent does not have required permissions for this operation"
  }
}

​

ベストプラクティス

1. 安全な保管: 環境変数やシークレットマネージャーで保護
2. ローテーション: 認証情報のローテーションポリシーを実装
3. スコープ最小化: 必要最小限の権限のみ要求
4. トークン更新: JWT の自動リフレッシュを実装
5. エラーハンドリング: 認証エラーをリトライロジックで適切に処理

​

認証テスト

export ADCP_AUTH_TOKEN="1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ"
export AGENT_URL="https://agenticadvertising.org/api/training-agent/mcp"

{
  "agent_uri": "https://agenticadvertising.org/api/training-agent/mcp",
  "protocol": "mcp",
  "auth": {
    "type": "bearer",
    "token": "1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ"
  }
}