認証

WebhookのURLを知っている人なら誰でもリクエストを送信できるため、認証を行うことで、第三者がShopify Flowのワークフローを意図せず実行してしまうのを防ぐことができます。設定は、各Webhookの「**セキュリティ」**セクションで行ってください。

3つの方法

方法	呼び出し元が自身を証明する方法	次のような場合に使用してください
なし	特にありません	テスト用のみです。本番環境では絶対に使用しないでください。
静的トークン	リクエストヘッダー内の固定された秘密情報	ほぼすべての連携機能（n8n、Make、Zapier、独自のコードなど）
HMAC SHA-256	リクエストと共有秘密鍵から計算された署名	送信者は、自身のWebhook（Stripe、GitHub、Slackなど）に署名を行います。

静的トークン

Webhookの「生成」ボタンを押して、強固なランダムトークンを取得するか、ご自身で用意したトークンを貼り付けてください。呼び出し元は、これをヘッダーとして送信します：

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

ヘッダー名の変更

一部のシステムでは、すでに使用しているヘッダーしか送信できない場合があります。その場合は、「詳細設定」で**「Authヘッダー名」**を設定してください。そうすれば、X-Api-Keyの代わりに、そのヘッダーからトークンを読み取ります：

  -H "X-Custom-Auth: your-token"

ヘッダー名は大文字小文字を区別しません。Host、Authorization、Cookie、X-Forwarded-*、X-Webhook-*、CF-* などの予約済み名は使用できません。これらはプロキシやCDNによって設定または書き換えられるため、そこから読み取られたトークンは攻撃者に制御される恐れがあります。

トークンの移動経路

すべての送信者が任意のヘッダーを追加できるわけではありません。送信者はどのようにトークンを渡すのでしょうか？「Webhook」タブには、以下の4つの場所が用意されています：

選択	送信者は次のように送信します	次のような場合に使用してください
カスタムヘッダー内では	X-Api-Key: <token>、またはご自身で指定したヘッダー名	デフォルトの設定であり、ほとんどの連携機能ではこのように動作します
ベアラー型トークンとして	Authorization: Bearer <token>	このツールには、「Bearer」または「APIトークン」フィールドがあります
ユーザー名とパスワードとして	HTTP Basic 認証で、ユーザー名はご自身で指定し、トークンをパスワードとして使用します	このツールでは、Basic認証のみが利用可能です
URL内では	?token=<token>、またはご指定のパラメータ名	送信者はプレーンなURLへの呼び出しのみが可能で、ヘッダーを設定することはできません

Authorization 意図的に予約済みのカスタムヘッダー名として残されています。「Bearer」と「Basic」がサポートされている使用方法であり、どちらも自動的に処理されます。これら2つのヘッダーに対する「401」リクエストでは、「WWW-Authenticate」ヘッダーも付加されます。これは、一部のHTTPクライアントが、チャレンジを受けた後にのみ認証情報を送信するためです。

URLオプションは4つのうち最もセキュリティが脆弱です。URLはログやリファラー、ブラウザの履歴に残ってしまうため、送信者から他に選択肢がない場合のみご利用ください。本アプリでは、トークンが含まれた完成したURLを表示しますが、リクエストを保存するすべての場所において、そのパラメータをマスキングします。

HMAC SHA-256

送信者は、共有秘密鍵を使用してリクエストに対する署名を生成します。私たちはそれを再計算し、照合します。漏洩したリクエストは、内容が改ざんされると、本文が署名と一致しなくなるため、リプレイ攻撃には利用できません。

プロバイダーのプリセット

「署名プロバイダー」から送信者を選択してください。当社では、そのプロバイダーの正確な方式（ヘッダー名、エンコーディング、署名対象、署名の有効期間など）に基づいて検証を行います。ダッシュボードから署名用シークレットを貼り付けるだけで、設定は完了です。

22種類の組み込みプロバイダーがあり、それぞれに独自のセットアップガイドが用意されています：Calendly、Customer.io、GitHub、Lemon Squeezy、Linear、Mollie、Paddle、Paystack、Razorpay、Sanity、Sendcloud、Sentry、Shopify、 Slack、Square、標準Webhook（OpenAI、Supabase）、Stripe、Svix（Clerk、Resend）、Typeform、Vercel、WooCommerce、Zendesk。お使いのサービスがリストにない場合は、カスタムスキームによる署名方法を説明してください。

完全なリスト、カスタムオプション、および組み込みの署名テスターについては、署名付きWebhookの検証 をご覧ください。

汎用HMAC

プリセットもカスタムスキームもないため、独自の方式を採用しています。具体的には、呼び出し元がX-Signatureを送信します。これは、署名用シークレットを使用して、X-Webhook-*ヘッダーの値に対してHMAC-SHA256を適用したものです。

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

「拒絶」とはどのようなものか

認証に失敗すると、401 が返され、JSON ボディに理由が記載されます。理由の完全な一覧については、沿革とトラブルシューティング をご覧ください。Webhook を編集中は、拒否された呼び出しが「Live Request Inspector」に引き続き表示されるため、呼び出しが失敗した正確な理由を確認することができます。

ダウンタイムなしでシークレットをローテーションする

1回の操作でシークレットを変更すると、送信者が変更に追いつくまで、古いシークレットで署名されたすべてのリクエストが失敗してしまいます。Webhook上でシークレットをローテーションすることで、この問題を回避できます。Webhookでは、静的トークンおよびすべての署名方式において、メインのシークレットと並行して受け入れられる、2つ目の有効なシークレットを保持するからです。

1. **「2つ目の有効な秘密」**に新しい秘密を入力し、保存してください。これで、両方が受け入れられるようになりました。
2. 送信者を新しい秘密鍵に切り替えてください。
3. **「プロモート」**をクリックすると、その項目がメインフィールドに移動し、2番目のフィールドがクリアされますので、保存してください。

どの段階においても、リクエストが拒否されることはありません。2つ目のシークレットはメインのシークレットとまったく同じ方法で保存され、APIからはそのシークレット自体が返されることはなく、設定されているかどうかの情報のみが返されます。

秘密をしっかりと守ること

• 当社のREST APIやMCPサーバーでは、どのアクセスレベルにおいてもトークンが返されることはありません。これらは どちらかが設定されているかどうかのみを報告します。開発者向けAPIとMCP をご覧ください。
• 保存時には暗号化されています。
• 回転させるとすぐに反映されますので、上記の「2つ目の秘密」のShopify Flowの手順を、 メインフィールドを上書きします。
• 保存された呼び出し履歴では、認証ヘッダー、Basic認証情報、およびURLトークンがマスクされます。 ですから、「履歴」のスクリーンショットを撮っても、秘密が漏れることはありません。

さらに絞り込む

認証は、呼び出し元が秘密情報を知っていることを証明するものです。IP許可リストは、呼び出し元を制限するものであり、上記のいずれのモードとも組み合わせることができます。