認可
このページは、MCP クライアントを開発またはデバッグする開発者向けです。既存のクライアントを接続したいだけの場合は、クライアントを接続を参照してください。
NameBeta は MCP の認可仕様に準拠しています。MCP エンドポイントが OAuth 2.1 のリソースサーバー、auth.namebeta.com にある NameBeta のアカウントサービスが認可サーバーです。ユーザーは NameBeta アカウントでサインインします。API キーはありません。
概要
| 項目 | 値 |
|---|---|
| リソース | https://namebeta.com/api/mcp |
| Protected Resource Metadata(PRM) | https://namebeta.com/.well-known/oauth-protected-resource/api/mcp |
| 認可サーバー(issuer) | https://auth.namebeta.com/oidc |
| クライアント登録 | Client ID Metadata Document(CIMD)または事前登録。DCR には非対応 |
| グラント | PKCE(S256)付きの認可コードグラント |
| スコープ | profile email。API 用のスコープはありません |
| トークン | JWT。Authorization: Bearer <token> として送信 |
全体の流れ
Client namebeta.com auth.namebeta.com
│ POST /api/mcp (no token) │ │
│────────────────────────────────▶│ │
│ 401 + WWW-Authenticate │ │
│◀────────────────────────────────│ │
│ GET PRM │ │
│────────────────────────────────▶│ │
│ { resource, authorization_servers, scopes_supported } │
│◀────────────────────────────────│ │
│ GET /oidc/.well-known/openid-configuration │
│────────────────────────────────────────────────────────────────▶│
│ authorization code + PKCE, resource=https://namebeta.com/api/mcp│
│────────────────────────────────────────────────────────────────▶│
│ user signs in and consents, client gets a token │
│◀────────────────────────────────────────────────────────────────│
│ POST /api/mcp, Authorization: Bearer <JWT> │
│────────────────────────────────▶│ │
│ 200 │ │
│◀────────────────────────────────│ │
1. 401 チャレンジ
トークンのないリクエストには 401 Unauthorized が返ります。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://namebeta.com/.well-known/oauth-protected-resource/api/mcp", scope="profile email"
Content-Type: application/json
{"jsonrpc":"2.0","error":{"code":-32000,"message":"unauthorized"},"id":null}
認証情報をまったく含まないリクエストには、RFC 6750 §3.1 の規定どおり、error 属性のないチャレンジが返ります。トークンの検証に失敗したリクエストには、同じチャレンジに error="invalid_token" を付加したものが返り、JSON-RPC のメッセージも invalid_token になります。
2. Protected Resource Metadata
GET https://namebeta.com/.well-known/oauth-protected-resource/api/mcp は、RFC 9728 のドキュメントを返します。
{
"resource": "https://namebeta.com/api/mcp",
"authorization_servers": ["https://auth.namebeta.com/oidc"],
"scopes_supported": ["profile", "email"],
"bearer_methods_supported": ["header"],
"resource_name": "NameBeta MCP"
}
チャレンジから resource_metadata を読み取らないクライアントのために、同じドキュメントはルートの https://namebeta.com/.well-known/oauth-protected-resource でも提供しています。レスポンスには Cache-Control: public, max-age=3600 が付きます。
3. 認可サーバーのメタデータ
issuer https://auth.namebeta.com/oidc にはパスが含まれており、メタデータはそのパスの後ろに well-known サフィックスを付けた URL でのみ公開しています。
| URL | ステータス |
|---|---|
https://auth.namebeta.com/oidc/.well-known/openid-configuration | 200 |
https://auth.namebeta.com/oidc/.well-known/oauth-authorization-server | 200 |
https://auth.namebeta.com/.well-known/oauth-authorization-server/oidc | 404 |
MCP の仕様では、クライアントはまずパスを挿入した RFC 8414 形式の URL を試し、次に OpenID Connect のディスカバリーにフォールバックすることになっています。そのため、仕様に準拠したクライアントは 1 つ目の URL にたどり着きます。メタデータでは client_id_metadata_document_supported: true と code_challenge_methods_supported: ["S256"] を公開しており、registration_endpoint はありません。
4. クライアント登録
NameBeta は Client ID Metadata Document(CIMD)に対応しています。client_id は HTTPS の URL で、その URL にあるドキュメントがクライアントの名前やリダイレクト URI などを記述します。認可サーバーは認可の過程でこのドキュメントを取得するため、登録の手順はありません。
動的クライアント登録(DCR、RFC 7591)は提供していません。DCR でしか自身を登録できないクライアントは、「does not support dynamic client registration」のようなエラーで停止します。
事前登録済みのクライアント ID
メタデータドキュメントを使えないクライアント(DCR にしか対応していないものなど)でも、ユーザーが OAuth のクライアント ID を入力できれば接続できます。クライアントの名前と使用するリダイレクト URI を添えて contact@namebeta.com までご連絡いただければ、クライアント ID をお送りします。クライアント ID の設定場所はクライアントによって異なります。
| クライアント | クライアント ID の設定場所 |
|---|---|
| Claude Code | claude mcp add … --client-id <client ID> |
| Codex | codex mcp add … --oauth-client-id <client ID> |
| Cursor | mcp.json のサーバーの auth ブロックにある CLIENT_ID |
| Gemini CLI | settings.json のサーバーの oauth.clientId |
| Devin Desktop | devin mcp login … --oauth-client-id <client ID> |
Cursor と Gemini CLI は Client ID Metadata Document ではなく動的クライアント登録でしか自身を登録できないため、常に NameBeta 発行のクライアント ID が必要です。
5. 認可リクエスト
PKCE(code_challenge_method=S256)付きの認可コードグラントを使い、RFC 8707 の resource パラメーターを送信します。
resource=https://namebeta.com/api/mcp
scope=profile email
- スコープ。 チャレンジと PRM が示すとおり、
profile emailをリクエストします。これらは ID 用のスコープで、同意画面ではクライアントがどのアカウント情報を参照できるかがユーザーに表示されます。mcp:toolsのような API 用のスコープはないため、リクエストしないでください。 - リフレッシュトークン。 リフレッシュトークンを取得するには、スコープに
offline_accessを追加し、prompt=consentを送信します。prompt=consentがないとoffline_accessは何も通知されずに無視され、アクセストークンだけが発行されます。 - resource。 サーバーが検証するのはこの値です。省略してもトークンは NameBeta MCP 向けに発行されますが、MCP の仕様で必須とされているため必ず送信してください。
ユーザーが初めていずれかのクライアントを認可すると、NameBeta は言語を英語、通貨を USD としてアカウントを作成します。どちらも namebeta.com で変更できます。
6. エンドポイントの呼び出し
すべてのリクエストで、アクセストークンを Authorization: Bearer <token> として送信します。完全なリクエストの例はエンドポイントとトランスポートにあります。
サーバーによるトークンの検証
サーバーは issuer の JWKS(https://auth.namebeta.com/oidc/jwks)で JWT の署名を検証したうえで、次のクレームを確認します。
| クレーム | 要件 |
|---|---|
iss | https://auth.namebeta.com/oidc |
aud | https://namebeta.com/api/mcp |
exp | 存在し、かつ未来の時刻であること |
sub | 存在すること。NameBeta のユーザーを識別します |
スコープは検証しません。認可の境界はオーディエンスです。https://namebeta.com/api/mcp 向けに発行されたトークンは、すべてのツールで有効です。いずれかの検証に失敗すると 401 と error="invalid_token" が返るので、トークンを更新するか、もう一度認可を行ってください。よくある原因はトラブルシューティングにまとめています。