> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# Auth グレーダー

> RFC 9421 リクエスト署名適合性、OAuth ハンドシェイク診断、Ed25519/P-256 署名鍵生成と検証のための AdCP CLI グレーダー。

`@adcp/sdk` 5.21+ は認証適合性のための CLI グレーダーを出荷します。それらは [コンプライアンスストーリーボード](/docs/building/verification/validate-your-agent) とは別です — ストーリーボードはプロトコル動作をエンドツーエンドでテストし、これらのグレーダーは認証と署名の層を特にテストし、ベクターごとの診断と仮説ランク付けされた失敗分析を与えます。

<Tip>
  下のすべてのコマンドは `npx @adcp/sdk@latest` を使います。`@adcp/sdk` をグローバルにインストール（`npm install -g @adcp/sdk`）している場合、`npx @adcp/sdk@latest` プレフィックスを落として `adcp` を直接使えます。
</Tip>

## リクエスト署名グレーダー

RFC 9421 適合性をエージェントに対してエンドツーエンドで検証します。すべての署名ベクターを実行しベクターごとの結果をレポートするため、どの正準化ルールやヘッダーカバレッジチェックが失敗しているかを正確に追跡できます。

```bash theme={null}
npx @adcp/sdk@latest grade request-signing <agent-url>
```

**確認するもの:**

* 署名ベース正準化（method、target-uri、authority、content-type、content-digest）
* カバードコンポーネントの完全性と順序
* `alg` と `kid` フィールドの存在と有効性
* タイムスタンプウィンドウ（±60 s）と nonce の一意性
* リプレイ検出（エージェントがアドバタイズする場合）
* 否定ベクター拒否 — 各不正な形式のリクエストは期待されるエラーコードを生成しなければならない（MUST）

**いつ使うか:** `get_adcp_capabilities` で任意の操作を `required_for` に切り替える前。当事者が署名検証失敗をレポートするとき。鍵アルゴリズムをアップグレードするとき（Ed25519 → P-256 またはその逆）。

## OAuth ハンドシェイク診断

エージェントの OAuth ディスカバリードキュメント（RFC 9728 protected-resource メタデータ、RFC 8414 authorization-server メタデータ）をプローブし、authorization code + PKCE フローを実行し、結果の JWT をデコードし、何が間違っているかについて仮説をランク付けします。

```bash theme={null}
npx @adcp/sdk@latest diagnose-auth <alias|url>
```

`<alias>` 形式は `~/.adcp/config.json` の保存されたエイリアス（`npx @adcp/sdk@latest --save-auth <alias> <url>` 経由で設定）を使います。

**プローブするもの:**

* `/.well-known/oauth-protected-resource` — 存在、`authorization_servers` リスト、HTTPS 強制
* `/.well-known/oauth-authorization-server` — issuer 一致、`token_endpoint`、`code_challenge_methods_supported`
* トークンエンドポイントレスポンス — トークンタイプ、有効期限、scope カバレッジ
* JWT クレーム — `iss`、`sub`、`aud`、`exp`、`iat` の存在と有効性
* クロスオリジン `authorization_servers` issuer ピン留め（リソースメタデータの AS URL が帯域外設定に一致しない場合フラグ）

**出力:** ランク付けされた仮説リスト、例: `1. token_endpoint not reachable (connection refused) — likely cause`、`2. issuer mismatch — AS URL returned by protected-resource does not match adagents.json`。各仮説は該当する仕様セクションにリンクします。

**いつ使うか:** bearer トークン設定の後 `AUTH_REQUIRED` エラーが持続するとき。動的クライアント登録が予期しないレスポンスを返すとき。新しいセラーの OAuth セットアップが黙って失敗するとき。

## 鍵生成

エージェントの `jwks_uri` での公開用にフォーマットされた Ed25519 または P-256 キーペアを生成します。

```bash theme={null}
npx @adcp/sdk@latest signing generate-key
```

出力:

* 秘密鍵ファイル（PEM、エージェントの署名設定用）
* `"kid"`、`"use": "sig"`、`"key_ops": ["verify"]`、`"adcp_use": "request-signing"`、`"alg": "EdDSA"`（または P-256 の `"ES256"`）を持つ、JWKS エンドポイントに貼り付け可能な JWK

**いつ使うか:** 初期署名セットアップ。鍵ローテーション（新しいものを生成、古いものと並べて公開、飛行中のリクエストをドレイン、古いものを退役）。

## ベクター検証者

完全なグレーダーを実行せずに単一の署名ベクターを検証します。実装中に特定の正準化ケースをデバッグするのに有用。

```bash theme={null}
npx @adcp/sdk@latest signing verify-vector
```

stdin からベクター（[`/compliance/latest/test-vectors/request-signing/`](https://adcontextprotocol.org/compliance/latest/test-vectors/request-signing/) のテストベクタースキーマに一致する JSON）を読み、クライアントの署名ベースが期待される出力に一致するかをレポートします。

**いつ使うか:** 署名クライアントを実装しながら、エンドツーエンドでテストする前に各コンポーネントルールを分離して確認するとき。

## 関連

* [エージェントを検証する](/docs/building/verification/validate-your-agent) — ストーリーボードベースのプロトコルコンプライアンステスト
* [Authentication](/docs/building/by-layer/L2/authentication) — 認証モデル概要、bearer トークン、RFC 9421 導入
* [セキュリティ実装リファレンス](/docs/building/by-layer/L1/security#署名付きリクエストトランスポート層) — 完全な RFC 9421 プロファイル、検証者チェックリスト、鍵公開ルール