メインコンテンツまでスキップ

認証方式

Custom エンドポイントへの配信時、受信側で正規の Recho からの通知であることを検証するために、3 種類の認証方式から選択できます。

備考

Slack / Teams / Email は対応エンドポイント自体が認証情報を含む URL / アドレスなので、本機能は Custom 限定です。

NONE（認証なし）​

認証ヘッダや署名なしで送信されます。受信側の URL を秘匿していて推測困難な場合などに利用してください。

警告

本番運用では他方式の採用を推奨します。

BEARER（Bearer トークン）​

ダッシュボードで生成したトークンを、リクエストの Authorization ヘッダにセットして送信します。

リクエストヘッダ例​

Authorization: Bearer <your-token>
Content-Type: application/json

受信側の検証​

  • 事前にエンドポイントに登録したトークンと一致するか比較
  • 不一致なら 401 で拒否

トークン管理​

  • 登録: Webhook 設定ページの認証情報ダイアログ
  • 表示: 一度作成すれば再表示可能（マスキング解除でコピー可）
  • 更新・削除: 同ダイアログから

SIGNATURE_RSA_SHA256（RSA 署名検証）​

Recho 側で生成した秘密鍵で署名し、対応する公開鍵を受信側で検証する方式。Bearer トークンより漏洩リスクが低く、推奨される方式です。

リクエストヘッダ例​

X-Recho-Signature: <base64-encoded-signature>
X-Recho-Timestamp: <unix-epoch-seconds>
Content-Type: application/json

受信側の検証手順​

  1. 署名対象文字列を組み立てる: <timestamp> + "." + <raw-body>
  2. 事前に登録した公開鍵で RSA-SHA256 署名検証 を実行
  3. タイムスタンプが許容ウィンドウ内（5 分以内など）であることを確認（リプレイ攻撃対策）
  4. いずれかが不正なら 401 で拒否

公開鍵管理​

  • 登録: 認証情報ダイアログで公開鍵を確認・コピー
  • 表示: 公開鍵は秘匿情報ではないので常に表示可能
  • ローテーション: 鍵を更新すると新しい公開鍵が発行されます

推奨​

  • 本番運用では SIGNATURE_RSA_SHA256 を強く推奨
  • 簡易な検証で十分な場合は BEARER。トークンは安全に保管・定期ローテーション
  • NONE は社内ネットワーク内など限定的な用途で