この記事では、HTTPベースのWebhookコネクターの異なる認証方法を構成する方法について説明します。
BasicAuth
BasicAuth Webhookは、HTTPヘッダーフィールド Authorization を使用した基本的なHTTP認証を使用する統合に使用します。認証情報は {username}:{password} のBase64エンコードされた文字列として渡されます。
BasicAuth認証のための以下の構成を使用してください:
| 構成 | 説明 |
|---|---|
| 名前 | (必須) Webhookの説明的なタイトル。 |
| BasicAuth ユーザー名 | Webhook認証のためのユーザー名。 |
| BasicAuth パスワード | Webhook認証のためのパスワード。 |
OAuth2 (3-legged)
OAuth2 3-legged Webhookは、ユーザー同意の認証フローが必要な統合に使用します。この方法はユーザーをプロバイダーの同意ページにリダイレクトし、認証コードを取得し、それをアクセストークンと交換します。その後、Webhookはそのトークンを使用してユーザーの代わりにリクエストを認証します。
OAuth2メソッドはサーバーサイドアプリケーションのみをサポートします。
OAuth 2.0サービスにWebアプリケーションを登録し、リダイレクトURLを許可するように構成する必要があります: https://my.tealiumiq.com/oauth/webhook/callback.html
OAuth2 (3-legged)認証のための以下の構成を使用してください:
| 構成 | 説明 |
|---|---|
| 名前 | (必須) Webhookの説明的なタイトル。 |
| クライアントID | (必須) OAuthサービスから割り当てられたアプリケーションのクライアント識別子。 |
| クライアントシークレット | (必須) アプリケーションに割り当てられたクライアントシークレット。 |
| スコープ | アプリケーションへのアクセスに要求する許可のタイプ。 |
| 認証URL | (必須) ユーザーを認証後にリダイレクトするURL。 |
| 認証URLクエリパラメータ | 認証URLのための一つ以上の名前-値ペアを入力してください。複数のペアを使用する場合はアンパサンド (&) を使用して区切ります。アンパサンド (&) を先頭に使用しないでください。正しい例: access_type=offline&prompt=consent誤った例: &access_type=offline&prompt=consent |
| アクセストークンURL | (必須) リフレッシュトークンを取得するためのトークンURL。 |
| 認証トークンの位置 | 認証トークンを配置する場所を指定してください。 |
| 認証ヘッダープレフィックス | デフォルト値は Bearerです。新しい値を指定して上書きする(一部のOAuth2サービスで必要)。 |
OAuth2 (2-legged)
OAuth2 2-legged Webhookは、ユーザーの関与なしにサーバー間認証に依存する統合に使用します。この方法では、クライアント資格情報(クライアントIDとシークレット)をプロバイダーから直接アクセストークンと交換します。その後、Webhookはそのトークンを使用してシステムへのリクエストを認証します。
OAuth2 (2-legged)認証のための以下の構成を使用してください:
| 構成 | 説明 |
|---|---|
| 名前 | (必須) Webhookの説明的なタイトルを入力してください。 |
| アクセストークンURL | (必須) アクセストークンを要求するAPIエンドポイントURLを入力してください。 |
| クライアントID | (必須) WebアプリケーションのクライアントIDを入力してください。 |
| クライアントシークレット | (必須) Webアプリケーションのクライアントシークレットを入力してください。 |
| ユーザー名 | ユーザー名を入力してください。パスワードグラントタイプを使用する場合はユーザー名が必要です。 |
| パスワード | パスワードを入力してください。パスワードグラントタイプを使用する場合はパスワードが必要です。 |
| クライアント認証ID | 認証ヘッダーの一部として送信するクライアントID。 |
| クライアント認証シークレット | 認証ヘッダーの一部として送信するクライアントシークレット。 |
| スコープ | 要求する権限の範囲を選択してください(一部のOAuth2サービスで必要)。 |
| 追加の認証パラメータ | 追加の認証パラメータを追加してください(一部のOAuth2サービスで必要)。複数のパラメータを & で区切ってください。 |
| 認証URL | (必須) 認証コードを要求するAPIエンドポイントURL。 |
| 認証トークンの位置 | 認証トークンを配置する場所を指定してください。 |
| 認証ヘッダープレフィックス | デフォルト値は Bearerです。新しい値を指定して上書きする(一部のOAuth2サービスで必要)。 |
| カスタムヘッダー | 認証コールに追加したいカスタムヘッダーのキーと値のペアをコンマ区切りで指定してください。例: 'header1:value1','header2:value2','header3:valuex,valuey'。 |
| カスタムボディ値 | キーと値のペアをコンマ区切りで定義してください。例: 'var1:value1','var2:value2','var3:varx,vary'。これらは Body Content Type フィールドで構成された形式に従ってボディに使用されます。 |
| ボディコンテンツタイプ | ボディコンテンツのタイプを指定してください。 |
| 認証値の位置 | 認証値(クライアントID、クライアントシークレット、ユーザー名、パスワード、スコープ)の位置を指定してください。 |
OAuth2 (2-legged) with mTLS
OAuth2 (2-legged) with mTLS Webhookは、相互TLS認証を組み合わせたサーバー間アクセストークンが必要な統合に使用します。クライアントシークレットの代わりに、Tealiumはトークンリクエスト中のTLSハンドシェイク中にエンドポイントにDigiCert発行のクライアント証明書を提示します。
OAuth2 (2-legged) with mTLS認証のための以下の構成を使用してください:
| 構成 | 説明 |
|---|---|
| キーアルゴリズム | クライアント証明書を生成するために使用されるアルゴリズム。セキュリティ要件に基づいて RSA-2048、RSA-3072、または RSA-4096 を選択してください。 |
| 2番目のレッグにmTLS暗号化を適用 | (オプション) 有効にすると、OAuth2トークンリクエストだけでなく、すべての配信リクエストのTLSハンドシェイク中にもクライアント証明書が提示されます。OAuth2認証ヘッダーはすべての配信リクエストで送信されます。トークンの取得は両方のモードで変わりません。無効にすると(デフォルト)、トークンリクエストのみがクライアント証明書を提示します。配信リクエストは標準のプラットフォームHTTPクライアントを使用します。APIがトークンエンドポイントだけでなくビジネスAPIコールでクライアント証明書の検証を要求する場合、この構成を有効にしてください。この構成を変更すると新しいバッチバッファが開始されます。すでにキューに入っているレコードは以前の構成で配信されます。 |
WebhookコネクターのためのOAuth2 (2-legged) with mTLS認証を構成するには:
- コネクタ構成で、認証タイプとして OAuth2 (2-legged) with mTLS を選択します。
- 配信リクエストにmTLSを適用するには、2番目のレッグにmTLS暗号化を適用 チェックボックスを選択します。
- キーアルゴリズム を選択し、生成 をクリックします。
- 証明書をダウンロード をクリックし、証明書をAPIゲートウェイまたはサーバーの管理者に提供します。
- プロファイルを保存して公開します。
証明書と秘密キーはプロファイルに保存され、バックアップコピーはありません。証明書を生成した後にプロファイルを保存して公開しない場合、証明書は保存されず、アクセスを回復するためにTealiumサポートに連絡する必要があります。
mTLS
Webhook mTLSコネクタは、特定の顧客のみが利用可能です。開始するには、Tealiumサポート担当者に連絡してください。
OAuth2トークンフローなしで相互TLS認証が必要な統合には、mTLS webhookを使用します。Tealiumは、配信リクエストごとにTLSハンドシェイク中にDigiCertが発行したクライアント証明書を提示します。クライアントID、クライアントシークレット、またはアクセストークンURLは使用されません。
mTLS認証のための以下の構成を使用してください:
- キーアルゴリズム:(必須)キーペアとDigiCertによって署名された公開証明書を生成するアルゴリズムを選択します。
- 生成されたキーペアと証明書は、配信リクエストごとのTLSハンドシェイク中にクライアント証明書として提示されます。
- 私有キーはPKCS#1形式(
-----BEGIN RSA PRIVATE KEY-----)で保存されます。PKCS#8キー(-----BEGIN PRIVATE KEY-----)はサポートされていません。
- テストエンドポイントURL:(オプション)mTLSハンドシェイクを検証するためにのみ使用されるHTTPSエンドポイント。
- このフィールドは配信URLではありません。配信URLはアクションごとに構成されます。
- テスト接続は常に証明書と私有キーの形式と有効期限を検証します。このフィールドを空白のままにすると、テスト接続はmTLSハンドシェイクを実行しません。
- このエンドポイントからの任意のHTTPレスポンスステータスは、ハンドシェイクが成功したことを確認します。
証明書と私有キーはバックアップコピーなしでプロファイルに保存されます。証明書を生成した後にプロファイルを保存および公開しない場合、証明書は保存されず、アクセスを回復するためにTealiumサポートに連絡する必要があります。
JWT
JWT webhookを使用して、署名されたJSON Webトークンを使用して認証する統合を行います。
JWT認証のための以下の構成を使用してください:
| 構成 | 説明 |
|---|---|
| 名前 | (必須)Webhookの説明的なタイトルを入力してください。 |
| JWTトークン | JSON Webトークンを入力してください。 |
OAuth2のアクセストークン
OAuth2を使用するWebhookリクエストは、リクエストでアクセストークンを提供する必要があります。OAuth2接続によって生成されたトークンは、{{webhook_access_token}}というテンプレート変数によってコネクタから提供され、APIごとに異なる方法で渡されます。次の例では、ヘッダーとしてAuthorization: Bearer TOKEN_HEREで期待されます。
このヘッダーを生成およびマッピングするための以下の手順を使用してください:
- 次の例を使用して
auth_templateというテンプレートを作成します:Bearer {{webhook_access_token}} - ヘッダーセクションで、このテンプレートをAuthorizationにマッピングします。

- 保存をクリックします。
- 変更を保存して公開します。
HTTPレスポンスクッキー
状態のないAPIと通信するサーバー間環境では、クッキーベースのセッション管理は一般的に推奨されません。そのため、webhookコネクタはクッキーベースのセッションを追跡せず、HTTPレスポンスのSet-Cookieヘッダー値を効果的に無視します。
最終更新日 :: 2026年August月5日