> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Auth for MCPを使用する理由

> ユーザーやそのAI agentがMCPサーバーに接続する前に、Auth0でユーザーを認証するメリット。

Auth for MCPはAuth0のユニバーサルログインに対応しているため、ユーザーはソーシャル、エンタープライズ、またはカスタムのIDプロバイダーを使ってサインインできます。Auth0から発行されるアクセストークンにはすべて、検証済みのアイデンティティコンテキストが含まれます。これにより、MCPでのやり取りはすべて信頼できるソースから開始されます。

## MCPで認証が重要な理由

* 安全で統制されたアクセス：ユーザーデータを保護し、MCPサーバーを利用できるユーザーとその権限範囲を管理します。また、MCPサーバーおよびクライアントを介して実行されたアクティビティについて、明確な監査証跡を残します。
* 監査可能性：監査やコンプライアンス対応に必要な、ユーザーのアクティビティ記録を提供します。

## Auth for MCP を使用する理由

MCP には、LLM がツールとやり取りするための標準化されたインターフェースや、豊富なコンテキストとメタデータを備えた LLM 向けツールなど、実用的な利点があります。

![MCP の図](https://mintlify.s3.us-west-1.amazonaws.com/auth0/docs/images/ai/mcp/mcp_diagram_light.png)

Auth0 を使用すれば、LLM がアクセストークンなどの機密情報にアクセスすることを心配せずに、ユーザーは信頼できるエージェントと安全にやり取りできます。Auth0 は、ファーストパーティ API とサードパーティ API のいずれについても、AI agent に対してスコープが限定され、アイデンティティに紐づいた最小権限のアクセスを適用します。

Auth0 は同意フローとクライアントごとの権限を管理し、Token Vault とトークン交換によって認証情報を保護します。さらに、ログの監査やライフサイクルイベントの追跡も可能です。

MCP 仕様では、Auth0 が提供する OAuth 2.1 の主要な機能がいくつか取り上げられています。

* **手動による Client ID Metadata Document (CIMD) 登録：** 安全で一元化された導入に欠かせない機能です。テナント管理者は、適切なクライアントメタデータ URI を指定して MCP クライアントを一度登録するだけで、複数のユーザーや環境に導入できます。
* **Proof Key for Code Exchange (PKCE) ：** [PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce.md) は、認可コードの傍受リスクを軽減する必須のセキュリティ機能で、Auth0 の SDK によって自動的に処理されます。
* **メタデータディスカバリー：** MCP 仕様で必須とされている機能です。サーバーは自身の OAuth エンドポイントを公開する必要があります。Auth0 テナントは [認可サーバーのディスカバリードキュメント](https://auth0.com/docs/get-started/applications/configure-applications-with-oidc-discovery.md#configure-applications-with-oauth-2-0-authorization-server-metadata) (`/.well-known/oauth-authorization-server`) を提供しているため、MCP クライアントは認可やトークン交換などに必要なエンドポイントを動的に検出でき、クライアント側での手動設定を減らせます。
* **サードパーティ IDプロバイダー (IdP) への認証の委任：** 仕様では、ユーザーのログイン処理を委任できます。Auth0 を信頼できる IDプロバイダーとして使用するよう MCPサーバーを設定すれば、ユーザー管理とサインオンのロジックを一元化できます。
* **On-Behalf-Of (OBO) トークン交換**：Auth0 のアクセストークンを、別のオーディエンス向けの新しいトークンセットと交換することで、ファーストパーティ API を呼び出せます。

## MCPサーバーのユーザー向け認証

Auth0は、アプリケーションに認証・認可サービスを手軽に組み込める柔軟なソリューションです。Auth0を使用すると、ユーザーは次の方法でログインできます。

* ユーザー名とパスワード
* [パスワードレスとパスキー](https://auth0.com/docs/authenticate/passwordless)
* [ソーシャルログイン (Google、Meta、Microsoft、GitHubなど) ](https://auth0.com/docs/authenticate/passwordless#social-login)
* B2B AIアプリケーション向けの[企業の認証情報とシングルサインオン (SSO) ](https://auth0.com/docs/authenticate/single-sign-on)
* その他

さらにAuth0では、セキュリティと拡張性を高める次の機能も利用できます。

* [多要素認証](https://auth0.com/docs/secure/multi-factor-authentication.md)
* [攻撃防御](https://auth0.com/docs/secure/attack-protection.md)：特定のIPからのトラフィックのブロックやCAPTCHAの表示などにより、攻撃を検知して、アプリケーションへの悪意あるアクセスを阻止します。ボット検知、Suspicious IP Throttling、ブルートフォース攻撃防御、漏えいパスワードの検知が含まれます。
* [ハイリーレギュレーテッドアイデンティティ](https://auth0.com/docs/secure/highly-regulated-identity.md)
* [アクション](https://auth0.com/docs/customize/actions.md)と[Form](https://auth0.com/docs/customize/forms.md)によるUIとログインフローのカスタマイズ

## Auth0を使用したMCPの認可フロー

以下は、MCPサーバーが認可サーバーとしてAuth0を使用する場合の標準的なOAuth認可コードフローです。

**Step 1**

MCPクライアントが保護されたMCPサーバーにリクエストを送信すると、HTTP `401 Unauthorized`が返されます。このとき、保護されたリソースのメタデータURLを示す`WWW-Authenticate`ヘッダーが含まれています。

**Step 2**

MCPクライアントは、MCPサーバーの`/.well-known/oauth-protected-resource`エンドポイントに[リソースメタデータ](https://datatracker.ietf.org/doc/html/rfc9728/)をリクエストします。

**Step 3**

MCPクライアントはメタデータを解析して一覧から認可サーバー (Auth0) を選択し、`/.well-known/oauth-authorization-server`エンドポイントからそのOAuth 2.0認可サーバーメタデータを取得します。メタデータのレスポンスを受け取った後、[Dynamic Client Registration (DCR) ](https://auth0.com/docs/get-started/applications/dynamic-client-registration.md#enable-dynamic-client-registration)が行われる場合があります。

**Step 4**

クライアントは[PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce.md)パラメーターを生成して認可リクエストを作成し、ブラウザーで認可エンドポイントを開きます。

**Step 5**

続いて、ユーザーがAuth0で認証します (ユーザー名/パスワード、ソーシャルログイン、またはMFAを使用) 。Auth0は、認可コードを付けてブラウザーをMCPクライアントの登録済みリダイレクトURIにリダイレクトします。

**Step 6**

MCPクライアントがトークンエンドポイントでコードを交換すると、Auth0がアクセストークンを返し、元のOAuthフローが完了します。

**Step 7**

アクセストークン (およびリフレッシュトークン) を受け取ると、MCPクライアントはそのアクセストークンを使用して、MCPサーバーのツールを認証済みの状態で呼び出します。

![Auth0の認証フロー](https://mintlify.s3.us-west-1.amazonaws.com/auth0/docs/images/ai/mcp/mcp_auth_flow_light.png)

Auth0を使用したMCPの認可フロー

## MCP向けエンタープライズアイデンティティ

エンタープライズ環境では、組織のIDプロバイダーとシングルサインオン (SSO) を使用して、MCPサーバーにアクセスするユーザーを認証できます。Auth0はOkta、Entra ID、Ping、Google WorkspaceなどのIdPと連携するため、従業員はMCP接続を開始する前に、既存の認証情報で認証できます。

このパターンには次の利点があります。

* MCPサーバーに対する従業員認証とMFAの統一
* アクセスポリシーの一元的な適用とデバイスポスチャーのチェック
* すべてのエージェントとのやり取りで一貫したセッションコンテキスト

エンタープライズアイデンティティを使用すると、MCPサーバーへのすべてのリクエストが、企業のセキュリティ対策で管理された検証済みの従業員アイデンティティから送信されることが保証されます。

## はじめに

MCPサーバーで Auth for MCP の利用を開始するには、以下のリソースを参照してください。

### クイックスタート

> **[MCPサーバーの認可](/ai/docs/ja-jp/mcp/get-started/authorization-for-your-mcp-server.md)**

> **[ユーザーに代わってファーストパーティAPIを呼び出す](/ai/docs/ja-jp/mcp/get-started/call-your-apis-on-users-behalf.md)**

### サンプルアプリ

> **[Task Vantage](https://github.com/auth0-samples/auth0-task-vantage)**

> **[Token Vault を使用した MCP](https://github.com/auth0-samples/auth0-ai-samples/tree/main/auth-for-mcp/xmcp-mcp-tokenvault-js)**

> **[On-Behalf-Of トークン交換を使用した MCP](https://github.com/auth0-samples/auth0-ai-samples/tree/main/auth-for-mcp/fastmcp-mcp-on-behalf-of-tokenexchange-js)**

> **[MCP サンプル](https://github.com/auth0-samples/auth0-ai-samples/tree/main/auth-for-mcp)**