MCP Registryの認証方式3種(GitHub/DNS/HTTP)を比較する

MCP Registryへの公開に認証が必要な理由

MCPの公式サーバーカタログであるMCP Registryへサーバーを公開する前には、必ず認証を済ませる必要があります。単なるログイン確認ではありません。どの認証方式を選ぶかが、サーバー名の名前空間そのものを決めます。GitHub認証を選べば io.github.username/* 形式、ドメイン認証(DNS・HTTP方式)を選べば所有ドメインの逆引きDNS形式(com.example.*/*)でしか登録できません。あとから認証方式を変えると、サーバー名自体を変える必要が出てくるので、公開前に選び切っておく価値があります。

3方式の全体像

MCP Registryが提供する認証方式は3つです。すべて mcp-publisher というCLIツールから実行します。

• GitHub認証: mcp-publisher が開始するOAuthフローで完結。GitHubアカウントさえあれば追加の設定作業はほぼ不要
• DNS認証: 公開鍵・秘密鍵のペアを生成し、公開鍵から作ったTXTレコードをドメインのDNSに追加する方式
• HTTP認証: DNS認証と同じ鍵ペアの仕組みを使うが、TXTレコードの代わりに /.well-known/mcp-registry-auth というファイルをドメイン上に置く方式

DNS認証・HTTP認証はどちらも、Ed25519またはECDSA P-384の鍵ペアを生成する必要があります。組織として複数のMCPサーバーを公開しつつ、社内の利用側では許可リストで使えるサーバーを絞り込む運用を組み合わせているチームもあり、公開側の認証設計と利用側の許可設計は別の管理軸として考える必要があります。

GitHub認証 — OAuthフローで最短に済ませる

個人開発者や小規模チームでいちばん準備が軽いのはGitHub認証です。サーバーのプロジェクトディレクトリで次のコマンドを実行するだけで完結します。

mcp-publisher login github

実行すると、デバイスコードとGitHubの認証URLが表示されます。

Logging in with github...
 
To authenticate, please:
1. Go to: https://github.com/login/device
2. Enter code: ABCD-1234
3. Authorize this application
Waiting for authorization...

表示されたURLをブラウザで開き、コードを入力して認可すれば、ターミナル側に「Successfully authenticated!」と表示されます。鍵の生成もDNSレコードの設定も不要で、3方式の中でもっとも準備が軽い方式です。ただし名前空間は必ず自分のGitHubアカウント名(または所属Organization名)に固定されます。独自ドメインでサーバー名を統一したいチームには向きません。

DNS認証 — TXTレコードでドメイン全体を証明する

自社ドメインを名前空間として使いたい場合はDNS認証を選びます。まず鍵ペアを生成し、TXTレコードの内容を作ります。

MY_DOMAIN="example.com"
openssl genpkey -algorithm Ed25519 -out key.pem
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "${MY_DOMAIN}. IN TXT \"v=MCPv1; k=ed25519; p=${PUBLIC_KEY}\""

出力されたTXTレコードを、自分が使っているDNSプロバイダーの管理画面に追加します。反映には数分かかることがあります。反映を確認したら、生成した秘密鍵を使ってログインします。

PRIVATE_KEY="$(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login dns --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"

DNS認証の強みは、ドメインのDNSレコードという、多くの組織が既に運用管理の仕組みを持っている場所に証明を置ける点です。一方で、DNSプロバイダーの管理画面への権限が必要になり、TXTレコードの伝播待ちという時間コストが発生します。

HTTP認証 — .well-knownファイルで証明する

DNSの管理権限は持っていないが、ドメイン配下にファイルを置く権限はある、というケースにはHTTP認証が向いています。鍵の生成方法はDNS認証と同じで、出力先がTXTレコードではなくファイルになる点だけが違います。

openssl genpkey -algorithm Ed25519 -out key.pem
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "v=MCPv1; k=ed25519; p=${PUBLIC_KEY}" > mcp-registry-auth

生成した mcp-registry-auth ファイルを、ドメインの /.well-known/mcp-registry-auth に配置します。たとえば https://example.com/.well-known/mcp-registry-auth としてアクセスできる状態にします。配置後のログインコマンドは、DNS認証とほぼ同じ形です。

MY_DOMAIN="example.com"
PRIVATE_KEY="$(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login http --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"

HTTP認証はDNSの伝播待ちが発生しない分、DNS認証より反映が速い傾向があります。ただし、静的ファイルをドメイン直下の .well-known パスに配置できるホスティング環境であることが前提になります。フロントエンドがCDN経由の静的配信ではなく、パス単位の制御が難しいSaaS型のホスティングを使っている場合、この配置自体が手間になることがあります。社内向けのマーケティングサイトと開発チームのAPIドメインが分かれている組織なら、開発チームが管理しているドメインの .well-known にファイルを置くほうが、マーケティング側のDNSに手を入れるより現実的な場合もあります。

鍵ファイルを扱いたくない組織向けの経路

DNS認証・HTTP認証は、ここまで見た通り秘密鍵をローカルの key.pem ファイルとして保存する手順が基本です。鍵ファイルをどこにも書き出したくない組織向けに、Google Cloud KMSやAzure Key Vaultに秘密鍵を持たせたまま署名する経路も用意されています。Google Cloud KMSを使う場合、鍵の作成からログインまで次のような流れになります。

gcloud kms keys create "mykey" --default-algorithm=ec-sign-ed25519 \
  --purpose=asymmetric-signing --keyring="mykeyring" --location=global
gcloud auth application-default login
mcp-publisher login dns google-kms --domain="example.com" \
  --resource="projects/myproject/locations/global/keyRings/mykeyring/cryptoKeys/mykey/cryptoKeyVersions/1"

秘密鍵の実体を一度もローカルに落とさずに済むため、鍵管理を情報システム部門やセキュリティチームに一元化している組織に向いています。Azure Key Vaultでも同様に、キー作成とログインコマンドの指定だけで完結する経路が用意されています。個人開発でここまでの構成を組む必要はほとんどなく、鍵管理の運用ルールが既に社内にある組織向けの選択肢と考えるのが実態に近いです。

状況別にどの方式が向くか

認証方式を後から変更するコストは軽くありません。公開済みのバージョンはメタデータごと変更できない仕様のため、名前空間を変えるということは、事実上サーバーを新しい名前で登録し直すことを意味します。既存の利用者が参照していた io.github.username/server のようなサーバー名は、そのまま残り続けます。認証方式の選び直しは、単なる設定変更ではなく実質的な移行作業になる点を踏まえて、最初の1回で決め切っておくと、後の移行作業を避けられます。

PostgreSQL MCPサーバーのように、企業のインフラチームが公式サーバーとして継続運用するケースでは、担当者個人のGitHubアカウントに紐づくGitHub認証よりも、組織のドメインに紐づくDNS・HTTP認証のほうが運用の引き継ぎに向いています。個人のOSS公開では、GitHub認証で足りることがほとんどです。鍵の管理や失効の運用まで考えると、追加の運用コストに見合わないことがほとんどです。企業として複数のMCPサーバーを自社ブランドの名前空間で統一公開したい場合は、DNSかHTTPのどちらかを選ぶことになります。すでにDNSの変更フローが確立している組織はDNS認証、逆にDNS変更には申請プロセスが必要だがWebサーバーへのファイル配置は開発チームの裁量でできる組織はHTTP認証、という切り分けが実務的です。

認証方式はサーバーの安全性を保証しない

3方式のどれを選んでも、MCP Registryが確認するのは「この名前空間の持ち主が公開操作をした」という一点だけです。コードの中身が安全かどうかは別の話で、認証を通過したサーバーが自動的に安全になるわけではありません。この設計は、MCP Registry自身がセキュリティスキャンを行わず、パッケージレジストリ側の検査とダウンストリームのアグリゲーターの追加チェックに委ねている構造と表裏一体です。認証方式を選ぶ作業は「誰が公開したか」を証明する作業であって、「何を公開したか」を審査してもらう作業ではない、という理解が実務上のつまずきを減らします。

ログアウトと再認証

mcp-publisher には logout コマンドも用意されており、保存済みの認証情報を破棄できます。認証方式を変更したい場合や、CIサーバーに一時的な認証情報だけを持たせて公開後すぐに破棄したい場合に使います。ログアウトしても、既にMCP Registryへ公開済みのサーバーやバージョンには影響しません。認証情報はあくまで「次に公開操作をする権限」を管理しているだけで、公開済みメタデータの所有権そのものを都度確認し直す仕組みではないためです。

CI/CDパイプラインに公開作業を組み込む場合、GitHub認証はGitHub Actions上でトークンを使って完結できるため相性がよく、公式でもGitHub Actionsによる自動公開の手順が案内されています。DNS認証・HTTP認証を自動化する場合は、秘密鍵をCIのシークレットストアに安全に保管する運用が前提になります。

まとめ

MCP Registryへの公開認証は、GitHub・DNS・HTTPの3方式です。選んだ方式がそのままサーバー名の名前空間の形式を決めるため、server.json を書き始める前に決めておく必要があります。個人・小規模開発ならGitHub認証で完結し、自社ドメインでの統一名前空間が必要な場合はDNSかHTTPのどちらかを、DNS管理権限の有無で選び分けます。

どの方式も、証明しているのは「誰が公開したか」だけで「何を公開したか」の安全性ではありません。この前提を理解したうえで認証を終えたら、次は server.json の内容を仕上げ、mcp-publisher publish で公開する流れに進みます。