本記事は「Auth for MCP Is Now Generally Available」を翻訳した記事です。
Model Context Protocol(MCP)はChatGPTやClaudeのようなAIエージェントが外部ツールやサービスに接続する標準的な方法になりました。エージェントがAPIを呼び出し、データを読み取り、アクションを実行するためのクリーンなインターフェースを提供します。しかしエージェントに操作を許可すべきかどうかの確認はしません。
深刻な問題です。適切な認証がなければMCPサーバーを見つけたエージェントは誰でも利用できます。身元確認も権限確認も一切されません。そしてリスクは高まり続けています。読み取り専用の統合ではありません。エージェントはトランザクションを実行し、顧客記録にアクセスし、本番システムを変更しています。
本日、より安全で本番環境に対応したMCPサーバーの提供を支援するアイデンティティレイヤーであるAuth for MCPの一般提供を発表します。
Auth for MCPとは？
Auth for MCPはあらゆるMCPサーバーに認証と認可を追加する簡単な方法を提供します。誰が何にアクセスできるかを正確に制御できます。
現在チームが構築している3つのパターンで機能します。
自社プロダクトと顧客のAIエージェント
顧客がAIエージェントからアクセスできるようにMCPを通じて機能を公開する場合、エンドユーザーと許可されている操作を把握する必要があります。たとえば顧客がシステム内の在庫データを取得したりワークフローをトリガーしたりする場合、実際の認証情報とスコープされた権限でやり取りを保護する必要があります。
自社プロダクトとエンドユーザーのAIエージェント
顧客はアプリのUIの代わりにChatGPTやClaudeのようなAIエージェントを通じて製品とやり取りし始めています。買い物客がエージェントにストアからランニングシューズを再注文するように頼みます。エージェントはユーザーとして認証し、権限を確認し、明確な境界内で行動する必要があります。消費者向けのエージェントのやり取りを可能にし、無謀にならずにシームレスに感じられる必要があります。
自社ツールと従業員のAIエージェント
従業員が仕事をより早く終わらせるのを助ける内部エージェントは今やどこにでもあります。ダッシュボードにクエリを実行し、チケットを更新し、ドキュメントを起草します。従業員はMCPを通じてSlack、Google Drive、Confluenceにアクセスする必要があります。適切な認証がなければインターンのエージェントはCFOと同じアクセス権を持ちます。現在のAIセットアップには誤って標準的な動作として扱っている大規模なセキュリティ上の欠陥があることを意味します。
今回のGAリリースに含まれる機能
Auth for MCPの仕組みを確認ください。
MCPサーバーを保護するための認証・認可機能の追加
Auth0はMCPサーバーの認証と認可の両方を処理します。認証側ではユーザー名とパスワード、ソーシャルログイン、エンタープライズSSOなど、すでにサポートしている任意の方法でユーザーがログインします。すでにAuth0を使用している場合、新しく設定するものはありません。
認可は興味深い部分です。MCPサーバーが到達できる内部APIを定義します。ユーザーのエージェントがAPIの呼び出しを必要とするアクションをトリガーすると、呼び出しが行われる前にAuth0は特定のユーザーに権限があるか確認します。エージェントは背後にいるユーザーに許可されていることだけを実行できます。
CIMD（Client ID Metadata Document）によるクライアント登録のサポート
MCPクライアントがMCPサーバーに接続するには身元を証明する必要があります。しかしサーバーは見たことのない新しいクライアントをどのように信頼するのでしょうか。同意画面の名前とロゴはどのように取得するのでしょうか。任意のクライアントが任意のサーバーに接続できるMCPのようなオープンなエコシステムにとって重要な課題です。
MCP仕様は当初Dynamic Client Registration(DCR)という従来のOAuthソリューションに依存していましたが、AIのスピードに合わせて構築されたものではありませんでした。現在ではCIMDを使用するように進化しました。複雑で1回限りの登録を合理化された自動プロセスに置き換え、数週間ではなく数分でエージェント群をデプロイして保護できます。
CIMDを使用すると各クライアントはクライアントを識別するURLでメタデータを含むドキュメントをホストします。Auth0ではテナント管理者がURLを提供し、Auth0がメタデータを取得して検証し、クライアントを作成する前に確認のために管理者に表示します。どのクライアントがMCPサーバーにアクセスできるかを制御し、予期しない登録を防ぎます。詳細についてはDCRよりもCIMDを使用する利点についての詳細な比較を記述しました。
CIMDを使用してアプリケーションを登録する方法を学びます。Register Applications with CIMDを確認ください。
On-Behalf-Of (OBO) トークン交換
本記事ではすぐに発生するシナリオを紹介します。ユーザーのエージェントがMCPサーバーで認証し、ジョブを完了するためにサーバーがSalesforceインスタンスやHRシステムなどの別のAPIを呼び出す必要がある場合です。問題は2番目のAPIがリクエストの正当性と実際の対象者をどのように知るかです。OBOトークン交換によりMCPサーバーはユーザーのアクセストークンをダウンストリームAPIで機能するトークンと交換できます。正しくスコープされ、元のユーザーに結び付けられたままです。共有シークレットや権限が大きすぎるサービスアカウントはありません。すべてのアクションに対する完全な監査と可視性を提供します。
const obo = await apiClient.getTokenOnBehalfOf(incomingAccessToken, { audience: "https://calendar-api.acme.com", scope: "calendar:read calendar:write", });
On-Behalf-Of(OBO)トークン交換の使用方法を学びます。On-Behalf-Of Token Exchangeを確認ください。
リソース識別子のサポート
MCP仕様ではOAuthが従来使用してきたaudienceパラメーターではなく、リソース識別子を使用してエージェントが通信したいサーバーを示します。Auth0はこれをネイティブにサポートするようになりました。MCPの実装は回避策や変換レイヤーなしで仕様に準拠したままになります。
はじめてみましょう！
つい昨年までMCPは好奇心の対象でした。今日では主要なプラットフォームがサポートし、チームは本番環境で構築しています。素晴らしいデモと実際のデプロイメントのギャップはほぼ完全に信頼に関するものです。誰が呼び出しているか証明できますか。操作を制限できますか。後で監査できますか。
新しい質問ではありません。しかしエージェントというコンテキストは人々の不意を突く形で緊急性を高めます。認証なしでAPIを出荷することはないでしょう。MCPサーバーも同じ扱いを受けるべきです。
Auth for MCPはAuth0ダッシュボードで利用可能になりました。設定し、最初のクライアントを登録し、エージェントを正面から受け入れます。Auth for MCPはClaude、Cursor、VSCode、ChatGPTなどのお気に入りのAIエージェントと連携します。