メインコンテンツへスキップ

アーキテクチャ

すべての API リクエストはゲートウェイを通過し、バックエンドサービスに転送される前に認証情報が検証されます。ゲートウェイは認証とクォータチェックを内部の認証・課金サービスに委任し、すべてのリクエストが 1 ホップで検証されるようにしています。 認証に失敗すると、ゲートウェイはバックエンドを経由せず直接エラーを返します(401 Unauthorized、または x402 が有効な場合は 402 Payment Required)。

3 つの認証方式

ChainStream は3 つの認証情報タイプをサポートしており、以下の優先順位で評価されます:
有効な認証情報が見つからず、x402 が有効な場合、ゲートウェイは HTTP 402 Payment Required を返し、/x402/purchase へのポインターを提供します。これにより AI エージェントがサブスクリプションを自動購入できます。

方式 1: API Key(推奨)

最もシンプルな認証方式です。Dashboard で API Key を作成し、X-API-KEY ヘッダーに渡します。

API Key の取得

1

Dashboard にログイン

ChainStream Dashboard にアクセスしてログイン
2

Applications に移動

サイドバーで「Applications」を見つけます
3

新しいアプリを作成

「Create New App」をクリックして API Key を生成します

API Key の使用

仕組み

  1. ゲートウェイが X-API-KEY ヘッダーを抽出
  2. 認証サービスがデータベースに対してキーを検証
  3. 成功すると、関連するオーガニゼーションと権限コンテキストを付与してリクエストが転送される
  4. キーは active であり、期限切れでないことが必要
API Key を安全に保管してください。コードリポジトリにコミットしないでください。漏洩した場合は、Dashboard で直ちに無効化してください。

方式 2: JWT Bearer Token (OAuth 2.0)

OAuth 2.0 Client Credentials フローを使用するアプリケーション向けです。Client ID と Client Secret を使用して JWT アクセストークンを取得します。

アクセストークンの生成

トークンの使用

仕組み

  1. ゲートウェイが Authorization: Bearer <jwt> ヘッダーを抽出
  2. 認証サービスが JWT 署名、発行者、オーディエンスを検証
  3. client_id クレームがクォータ追跡用のオーガニゼーションに解決される

トークンの詳細

  • 有効期間: デフォルトで 24 時間
  • アルゴリズム: RS256
  • 発行者: https://dex.asia.auth.chainstream.io/
  • オーディエンス: https://api.dex.chainstream.io

スコープ権限

特定のエンドポイントには特定のスコープが必要です:
スコープを指定しない場合、トークンはすべての一般 API エンドポイントにアクセスできます。スコープは Webhook と KYT エンドポイントにのみ必要です。

方式 3: ウォレット署名 (SIWX)

x402 支払いでサブスクリプションを購入したオンチェーンウォレットを持つ AI エージェント向けです。Sign-In with X (SIWX) 標準(EVM 向けの EIP-4361、Solana 向けの同等規格)を使用します。

仕組み

  1. エージェントがドメイン、アドレス、ナンス、有効期限を含む標準的なサインインメッセージを構築
  2. エージェントがウォレットの秘密鍵でメッセージに署名
  3. 署名されたトークンを Authorization: SIWX base64(message).signature として送信
  4. 認証サービスが署名を検証し、有効な x402 サブスクリプションを確認
  5. 有効で期限切れでないサブスクリプションが存在すれば、認証成功

トークンフォーマット

メッセージは EIP-4361 フォーマットに準拠:

対応チェーン

SDK の使用

SIWX 認証にはアクティブな x402 サブスクリプションが必要です。サブスクリプションが期限切れの場合、リクエストは拒否されます。サブスクリプションの購入については、x402 支払いを参照してください。

WebSocket 認証

WebSocket 接続は同じ 3 つの認証方式を使用します。ゲートウェイは以下を行います:
  1. WebSocket アップグレードリクエストを検出
  2. ハンドシェイクを許可する前に認証情報を検証
  3. 使用量メータリングのためにセッションを追跡
  4. 切断時に使用量メトリクス(転送バイト数、接続時間)を報告
WebSocket トークンはクエリパラメータとしても渡せます:

認証の優先順位

1 つのリクエストに複数の認証情報が含まれる場合、以下の順序で評価されます:
  1. SIWXAuthorization ヘッダーが SIWX で始まり、x402 が設定されている場合
  2. API KeyX-API-KEY ヘッダーが存在する場合
  3. JWT BearerAuthorization ヘッダーが Bearer で始まる場合
  4. 402 Payment Required — 認証情報が一致せず、x402 が有効な場合
最初に成功したマッチが採用され、以降の方式は評価されません。

API エンドポイント


認証方式の選択

API Key

最適な用途: アプリケーション、スクリプト、CLI、MCP Server最もシンプルなセットアップ。Dashboard で作成し、ヘッダーに渡すだけ。トークンの更新は不要です。

JWT Bearer

最適な用途: Dashboard アプリ、サーバー間通信標準的な OAuth 2.0 フロー。スコープ付き権限をサポート。トークンの TTL は 24 時間。

SIWX ウォレット

最適な用途: オンチェーンウォレットを持つ AI エージェントx402 サブスクリプションによるウォレットネイティブ認証。API Key の管理は不要です。

FAQ

ほとんどのユースケースには API Key が推奨されます。セットアップが最もシンプルで、すべての ChainStream プロダクト(SDK、CLI、MCP Server)で使用できます。スコープ付き権限を持つ OAuth 2.0 統合が必要な場合は JWT を使用してください。独自のウォレットを持つ AI エージェントを構築し、x402 で支払いたい場合は SIWX を使用してください。
JWT の場合:Client ID と Client Secret を使用して新しいトークンを生成します。SIWX の場合:将来の有効期限を設定して新しいメッセージに署名します。API Key は、Dashboard で有効期限を設定しない限り期限切れになりません。
1 つのリクエストにつき 1 つの方式のみが評価されます。X-API-KEYAuthorization: Bearer の両方を送信した場合、API Key が優先されます(SIWX > API Key > JWT)。
有効な認証情報が見つからず、x402 が有効な場合、ゲートウェイは HTTP 402 を返し、/x402/purchase でサブスクリプションを購入するよう案内します。これにより AI エージェントがアクセスを自動購入できます。x402 支払いを参照してください。
API Key: Dashboard でアプリを削除します。キーは即座に無効化されます。JWT: Dashboard で Client ID/Secret を取り消します。SIWX: サブスクリプションは自然に期限切れとなり、手動での無効化はありません。