Auth0 CIMD para aplicaciones modernas, MCP y agentes de IA

TL;DR

CIMD significa Client ID Metadata Document. Permite que un cliente OAuth se identifique con una URL HTTPS que apunta a un documento JSON de metadatos.
Para MCP, CIMD ayuda a resolver un problema real de registro: los clientes y servidores MCP suelen encontrarse por primera vez en tiempo de ejecución, por lo que el registro previo manual no escala bien.
Auth0 ahora admite el registro manual de CIMD para aplicaciones de terceros. Un administrador del tenant importa la URL de CIMD, Auth0 obtiene y valida el documento, y la URL de CIMD se convierte en la identidad externa del cliente.
En el modelo Auth for MCP de Auth0, tu servidor MCP es un recurso protegido por OAuth, Auth0 es el servidor de autorización y el cliente o agente MCP debe obtener un token de acceso con los scopes correspondientes antes de invocar herramientas.
Para las aplicaciones modernas, CIMD no reemplaza el inicio de sesión, la validación de JWT, los scopes, las comprobaciones de autorización, los registros de auditoría ni el control de acceso granular. Es una forma más sencilla de registrar y reconocer clientes.
Para agentes de flujos de trabajo y orquestadores, el patrón para producción es: autenticar a la persona, identificar al agente o cliente, vincular los tokens al servidor MCP, intercambiarlos en nombre del usuario al llamar a APIs posteriores y comprobar los permisos a nivel de recurso antes de cada acción relevante.

El software basado en agentes hace que una pregunta de identidad muy antigua vuelva a sentirse nueva:

Who is calling this system,
on behalf of whom,
through which client,
for which resource,
with what permission,
and can I prove it later?

Esa pregunta antes correspondía sobre todo a los equipos de identidad empresarial. Ahora aparece en el trabajo habitual de producto: herramientas MCP, copilotos, agentes de soporte, creadores de flujos de trabajo, automatización interna, pipelines de RAG y agentes que llaman a otros agentes.

El nuevo soporte de CIMD en Auth0 importa porque ofrece a los equipos una forma práctica de resolver una parte de ese rompecabezas: cómo reconoce un servidor de autorización OAuth a un cliente en un mundo MCP dinámico.

Qué aprenderás aquí

Qué es CIMD y por qué existe
Cómo usa Auth0 CIMD con Auth for MCP
Cómo encaja el flujo de autorización de MCP con OAuth 2.1, los metadatos del recurso protegido, los metadatos del servidor de autorización, PKCE y los scopes
Cómo configurar desde cero un cliente respaldado por CIMD
Cómo proteger con Auth0 una aplicación web moderna, un servidor MCP, un agente de flujos de trabajo o un orquestador de agentes
Dónde termina el alcance de CIMD y dónde sigues necesitando autorización, intercambio de tokens, auditoría y controles de aprobación

La versión en una frase

CIMD permite que un cliente diga: «Mi client ID es esta URL HTTPS de metadatos», y que el servidor de autorización consulte esa URL para conocer el nombre del cliente, sus URI de redirección, logo, tipos de concesión y método de autenticación.

Ejemplo:

client_id = https://agent.example.com/oauth/client.json

Esa URL no es solo una cadena cualquiera. También es el lugar donde el cliente publica metadatos sobre sí mismo.

{
  "client_id": "https://agent.example.com/oauth/client.json",
  "client_name": "Acme Workflow Agent",
  "client_uri": "https://agent.example.com",
  "logo_uri": "https://agent.example.com/logo.png",
  "redirect_uris": ["https://agent.example.com/oauth/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Para un cliente público, token_endpoint_auth_method: "none" significa que el cliente no se autentica con un secreto en el endpoint de tokens. Debe usar PKCE en el flujo de código de autorización.

Para un cliente confidencial, CIMD puede usar private_key_jwt: el cliente publica las claves públicas mediante jwks_uri y firma la autenticación ante el endpoint de tokens con su clave privada.

Por qué existe CIMD

OAuth clásico supone que el cliente está registrado antes de que comience el flujo de autorización. Eso funciona bien cuando tu aplicación tiene una relación conocida con un proveedor de identidad.

Con MCP, la situación se complica.

Los clientes y servidores MCP están diseñados para combinarse entre sí. Un usuario puede conectar Claude Desktop, Cursor, VS Code, un agente personalizado o un orquestador de flujos de trabajo a un servidor MCP que el cliente nunca ha visto.

Sin CIMD, normalmente tienes tres opciones:

Enfoque	Funciona bien cuando	Problema
Registro previo	El cliente y el servidor ya tienen una relación	No se adapta bien a los ecosistemas MCP abiertos
Dynamic Client Registration	Los clientes desconocidos necesitan un registro automatizado	Puede generar problemas de limpieza operativa, abuso y crecimiento de la base de datos
Copiar y pegar client IDs manualmente	Los despliegues privados son pequeños	Mala experiencia de usuario y facilidad para cometer errores de configuración

CIMD cambia el panorama:

Client owns metadata URL
Authorization server fetches metadata
Client ID is stable across deployments
Admin can inspect the URL and metadata
OAuth flow continues with normal authorization code + PKCE

Es especialmente útil para MCP porque el cliente puede llevar consigo su identidad de una forma alineada con los estándares, sin necesitar un nuevo registro de cliente para cada combinación de servidor, usuario e instalación.

Cómo encaja Auth0

Auth for MCP de Auth0 sitúa a Auth0 como el servidor de autorización para clientes y servidores MCP.

El modelo general:

MCP Client / Agent
      |
      | needs access token
      v
Auth0 Authorization Server
      |
      | issues scoped token
      v
MCP Server / Tool Gateway
      |
      | optional token exchange
      v
Downstream APIs, workflows, data stores

Auth0 se encarga de:

autenticar usuarios mediante los proveedores de identidad que configuraste
emitir tokens OAuth/OIDC
proporcionar metadatos de descubrimiento basados en estándares
registrar clientes con CIMD
gestionar el consentimiento y los permisos definidos mediante scopes
intercambiar tokens en nombre del usuario para APIs posteriores

Tu aplicación sigue encargándose de:

validar tokens en las solicitudes a la API y al servidor MCP
hacer cumplir los scopes y permisos de recursos
decidir qué llamadas a herramientas están permitidas
registrar y auditar acciones
incorporar aprobación humana cuando el riesgo es alto

La pila de autorización de MCP

La autorización de MCP no es un protocolo de autenticación completamente nuevo. Combina varios componentes de OAuth.

Capa	Qué hace
OAuth 2.1	Flujo de código de autorización, PKCE, uso de bearer tokens y expectativas sobre refresh tokens
RFC 9728 Protected Resource Metadata	Permite que el servidor MCP indique a los clientes dónde se realiza la autorización
RFC 8414 Authorization Server Metadata	Permite que los clientes descubran los endpoints de autorización y de tokens de Auth0
CIMD	Permite que los clientes se identifiquen con una URL de metadatos
Resource Indicators	Vinculan los tokens al servidor o recurso MCP específico
Scopes	Expresan permisos generales como `tool:greet` o `files:read`
OBO Token Exchange	Permite que el servidor MCP llame a otra API conservando el contexto del usuario

Esa pila suena compleja, pero el flujo en tiempo de ejecución es fácil de entender.

User            MCP Client          MCP Server             Auth0              API
 |                  |                    |                    |                 |
 | asks agent       |                    |                    |                 |
 |----------------->|                    |                    |                 |
 |                  | unauth request     |                    |                 |
 |                  |------------------->|                    |                 |
 |                  | 401 + metadata     |                    |                 |
 |                  |<-------------------|                    |                 |
 |                  | discover Auth0     |                    |                 |
 |                  |----------------------------------------->|                 |
 |                  | auth request       |                    |                 |
 |                  | client_id=CIMD URL |                    |                 |
 |                  |----------------------------------------->|                 |
 | login + consent  |                    |                    |                 |
 |<---------------------------------------------------------->|                 |
 |                  | access token       |                    |                 |
 |                  |<-----------------------------------------|                 |
 |                  | call MCP tool      |                    |                 |
 |                  | Bearer token       |                    |                 |
 |                  |------------------->| validate token      |                 |
 |                  |                    | maybe exchange OBO  |                 |
 |                  |                    |------------------->|                 |
 |                  |                    | API-scoped token    |                 |
 |                  |                    |<-------------------|                 |
 |                  |                    | call API            |                 |
 |                  |                    |------------------------------------->|
 |                  |                    | result              |                 |
 |                  |<-------------------|<-------------------------------------|
 | response         |                    |                    |                 |
 |<-----------------|                    |                    |                 |

Desde cero: configura Auth0 CIMD

La configuración práctica tiene dos partes: los metadatos del cliente que alojas y la configuración del tenant de Auth0 que los importa.

1. Aloja un documento CIMD

Publica el documento en una URL HTTPS estable con una ruta real:

https://agent.example.com/oauth/client.json

La validación de URL de CIMD de Auth0 rechaza hosts de loopback local como localhost, 127.0.0.1 y ::1. La URL debe usar HTTPS, incluir una ruta además de / y no contener fragmentos, parámetros de consulta, credenciales, segmentos de puntos ni espacios en blanco.

Para un cliente MCP público:

{
  "client_id": "https://agent.example.com/oauth/client.json",
  "client_name": "Acme Agent Console",
  "description": "MCP client for Acme workflow automation",
  "client_uri": "https://agent.example.com",
  "logo_uri": "https://agent.example.com/logo.png",
  "application_type": "web",
  "grant_types": ["authorization_code", "refresh_token"],
  "redirect_uris": ["https://agent.example.com/oauth/callback"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Para un cliente confidencial:

{
  "client_id": "https://agent.example.com/oauth/client.json",
  "client_name": "Acme Agent Backend",
  "application_type": "web",
  "grant_types": ["authorization_code", "refresh_token"],
  "redirect_uris": ["https://agent.example.com/oauth/callback"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks_uri": "https://agent.example.com/oauth/jwks.json"
}

En el modelo de Auth0, jwks_uri debe compartir el mismo origen que la URL de CIMD.

2. Habilita CIMD en Auth0

En el Dashboard de Auth0:

Settings
  -> Advanced
    -> Client ID Metadata Document Registration

Para clientes MCP, Auth0 también recomienda habilitar el Resource Parameter Compatibility Profile para que las solicitudes de autorización puedan usar el parámetro resource cuando no se proporciona audience.

3. Obtén una vista previa del CIMD con la Management API

Antes de registrar el cliente, obtén una vista previa:

curl --request POST \
  --url "https://YOUR_AUTH0_DOMAIN/api/v2/clients/cimd/preview" \
  --header "Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "external_client_id": "https://agent.example.com/oauth/client.json"
  }'

Usa la vista previa como una verificación de CI para los metadatos de tu cliente. Así detectas problemas de validación antes de que el administrador del tenant registre el cliente.

4. Registra el cliente CIMD

Después de que la vista previa pase la validación:

curl --request POST \
  --url "https://YOUR_AUTH0_DOMAIN/api/v2/clients/cimd/register" \
  --header "Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "external_client_id": "https://agent.example.com/oauth/client.json"
  }'

Auth0 almacena un registro de la aplicación registrada, pero el CIMD alojado sigue siendo la fuente de verdad. Las actualizaciones de metadatos se sincronizan mediante una actualización manual.

5. Configura el acceso a la API

Para un servidor MCP, crea una API en Auth0 que represente el recurso MCP.

Ejemplos de scopes:

tool:greet
tool:search
tool:write
workflow:run
workflow:approve
documents:read

Usa nombres sencillos. Son más fáciles de auditar que los nombres ingeniosos.

Cómo proteger una aplicación web moderna

En una aplicación web normal, CIMD suele ser relevante cuando tu aplicación o integración actúa como cliente OAuth de un recurso protegido por Auth0. Tu aplicación sigue el mismo patrón fundamental:

Browser
  -> Web app frontend
    -> Backend route / server action / API route
      -> Validate Auth0 token
        -> Check scopes and resource permissions
          -> Perform action

Una función auxiliar de servidor al estilo Next.js podría verse así:

import { createRemoteJWKSet, jwtVerify } from "jose";

const issuer = `https://${process.env.AUTH0_DOMAIN}/`;
const audience = process.env.AUTH0_AUDIENCE!;
const jwks = createRemoteJWKSet(
  new URL(`https://${process.env.AUTH0_DOMAIN}/.well-known/jwks.json`)
);

export async function verifyAccessToken(token: string) {
  const { payload } = await jwtVerify(token, jwks, {
    issuer,
    audience,
  });

  return {
    subject: payload.sub,
    clientId: payload.client_id,
    scopes: String(payload.scope ?? "").split(" ").filter(Boolean),
    claims: payload,
  };
}

export function requireScope(scopes: string[], required: string) {
  if (!scopes.includes(required)) {
    throw new Response("Insufficient scope", { status: 403 });
  }
}

Eso es lo mínimo. Las aplicaciones reales en producción suelen agregar:

comprobaciones de pertenencia a organizaciones o espacios de trabajo
autorización a nivel de fila o documento
eventos de auditoría
límites de tasa por usuario, cliente, tenant y herramienta
aprobaciones explícitas para acciones irreversibles

Cómo proteger un servidor MCP

Un servidor MCP expone herramientas. Trátalo como un servidor de recursos.

Debe publicar metadatos del recurso protegido:

{
  "resource": "https://mcp.example.com",
  "authorization_servers": ["https://YOUR_AUTH0_DOMAIN"],
  "scopes_supported": [
    "tool:greet",
    "tool:search",
    "workflow:run"
  ],
  "resource_name": "Acme MCP Server",
  "bearer_methods_supported": ["header"]
}

Debe responder a las llamadas no autenticadas con un desafío que contenga información suficiente para que el cliente descubra cómo autenticarse:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                  scope="tool:search"

Y debe validar cada solicitud:

type ToolAuth = {
  subject: string;
  clientId?: string;
  scopes: string[];
};

export async function authorizeToolCall(
  token: string,
  requiredScope: string
): Promise<ToolAuth> {
  const auth = await verifyAccessToken(token);
  requireScope(auth.scopes, requiredScope);

  return {
    subject: auth.subject!,
    clientId: typeof auth.clientId === "string" ? auth.clientId : undefined,
    scopes: auth.scopes,
  };
}

La regla importante: nunca consideres que «el agente llamó a la herramienta» es suficiente. El token debe ser válido para ese servidor MCP, tener el scope correspondiente a la acción y estar vinculado al contexto de usuario o cliente que esperas.

Cómo llamar a APIs en nombre del usuario

Los servidores MCP suelen necesitar llamar a una API posterior.

Ejemplo:

User asks: "Summarize my invoices and draft a refund workflow."

MCP server needs:
- invoice API token
- customer support API token
- workflow API token

No pases el token de acceso de MCP a todas las APIs posteriores.

Usa el intercambio de tokens en nombre del usuario:

MCP access token
  audience = https://mcp.example.com
  scope    = tool:refund

exchange with Auth0

API access token
  audience = https://api.example.com
  scope    = refunds:write
  user     = same original user context

Pseudocódigo:

export async function exchangeOnBehalfOfUser(accessToken: string) {
  const response = await fetch(`https://${process.env.AUTH0_DOMAIN}/oauth/token`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      grant_type: "urn:ietf:params:oauth:grant-type:token-exchange",
      client_id: process.env.MCP_SERVER_CLIENT_ID,
      client_secret: process.env.MCP_SERVER_CLIENT_SECRET,
      subject_token_type: "urn:ietf:params:oauth:token-type:access_token",
      subject_token: accessToken,
      requested_token_type: "urn:ietf:params:oauth:token-type:access_token",
      audience: "https://api.example.com",
      scope: "refunds:write"
    })
  });

  if (!response.ok) {
    throw new Error("Token exchange failed");
  }

  return response.json() as Promise<{ access_token: string; scope?: string }>;
}

Los SDK de Auth0 encapsulan este proceso en los entornos compatibles, pero el modelo mental es el mismo: intercambia el token en el punto donde cambia la audiencia.

Agentes de flujos de trabajo y orquestadores

El caso de uso más interesante no es «el agente inicia sesión». Es «el agente realiza trabajo con límites definidos para una persona dentro de un flujo de trabajo más amplio».

Un buen modelo para producción separa cuatro identidades:

Identidad	Ejemplo	Por qué importa
Persona	`user:ana`	Consentimiento, propiedad, auditoría y responsabilidad de negocio
Cliente	`https://agent.example.com/oauth/client.json`	Qué aplicación inició el flujo OAuth
Agente	`agent:refund-drafter`	Qué agente autónomo realizó el paso
Tarea	`task:refund-9821`	Qué trabajo de alcance definido se aprobó

Esto da lugar a flujos como este:

Human approves task
      |
      v
Orchestrator creates task-scoped run
      |
      v
Agent invokes MCP tool
      |
      v
MCP server validates token + scope
      |
      v
Authorization layer checks resource permission
      |
      v
Tool executes or requests human approval

Para los PM, la pregunta de producto es:

What should the agent be allowed to do without asking again?

Para los ingenieros, la pregunta de implementación es:

Where do we encode that boundary so every tool path enforces it?

Los scopes son útiles, pero no bastan para modelar permisos de producto complejos.

Usa scopes para capacidades generales:

workflow:run
documents:read
refunds:write

Usa tu sistema de autorización para tomar decisiones a nivel de recurso:

Can user:ana view document:roadmap?
Can agent:refund-drafter draft refund for customer:123?
Can task:refund-9821 write to case:456 before manager approval?

Si ya usas Auth0 FGA u OpenFGA, aquí es donde corresponde usarlos.

Cuándo usar CIMD, registro previo o DCR

Usa CIMD cuando:

tu cliente y el servidor de autorización podrían no tener una relación previa
estás creando un cliente MCP, una plataforma de agentes o una integración de terceros
quieres una identidad de cliente estable basada en una URL
quieres que los administradores puedan inspeccionar una fuente de registro legible para personas
puedes alojar metadatos en un dominio HTTPS estable

Usa el registro previo cuando:

la integración es privada o propia
controlas ambos lados
los client IDs y las URL de callback se conocen de antemano
la simplicidad operativa importa más que el descubrimiento dinámico

Usa Dynamic Client Registration cuando:

tu ecosistema ya depende de él
el servidor de autorización tiene controles sólidos contra el abuso
no es razonable esperar que los clientes alojen metadatos
necesitas compatibilidad con versiones anteriores de clientes MCP

Lista de verificación para expertos

Antes de llevar esto a producción, revisa los detalles rutinarios. Ahí es donde reside la seguridad.

La URL de CIMD es estable, usa HTTPS, es lo suficientemente corta para que una persona pueda inspeccionarla y está alojada en un dominio que controlas.
El client_id dentro del JSON coincide exactamente con la URL del documento.
Las URI de redirección son exactas, mínimas y solo de producción, salvo que tengas una política de desarrollo definida.
Los clientes públicos usan el flujo de código de autorización con PKCE.
Los clientes confidenciales usan private_key_jwt, no secretos compartidos en los metadatos.
El servidor de autorización anuncia client_id_metadata_document_supported cuando admite CIMD.
Los metadatos del recurso protegido MCP están disponibles mediante el endpoint well-known o el desafío WWW-Authenticate.
Los tokens están vinculados al servidor MCP como audiencia.
Los servidores MCP rechazan tokens emitidos para otras APIs.
Las APIs posteriores obtienen sus propios tokens de acceso mediante el intercambio de tokens.
Los scopes de las herramientas son mínimos y, cuando es posible, se solicitan de forma incremental.
Los permisos granulares se comprueban en el servidor.
Los logs incluyen usuario, cliente, agente, tarea, recurso, scopes y decisión.
Las llamadas a herramientas sensibles requieren confirmación, aprobación o un control de políticas.
Los cambios de metadatos activan una revisión cuando cambian las URI de redirección, las claves, los tipos de concesión, los scopes, el nombre o el logo.

Errores comunes

Error 1: Tratar CIMD como autenticación

CIMD identifica al cliente. No autentica al usuario. Sigues necesitando el flujo normal de inicio de sesión OAuth/OIDC.

Error 2: Confiar demasiado en el nombre del cliente

Los metadatos del cliente pueden contener campos de presentación como el nombre y el logo. Estos ayudan a los usuarios a entender a qué dan su consentimiento, pero no son una señal de confianza suficiente por sí solos. Muestra los dominios claramente y mantén políticas de aprobación por parte de los administradores.

Error 3: Pasar el mismo token a todas partes

El token del servidor MCP debe estar destinado al servidor MCP. Si el servidor llama a una API posterior, intercámbialo por un token con el alcance adecuado para esa API.

Error 4: Usar scopes como modelo completo de permisos

Los scopes responden preguntas generales sobre capacidades. Por lo general, no pueden responder «¿puede este usuario acceder a este proyecto, ticket, factura o documento específico?».

Error 5: Olvidar la identidad no humana

En los sistemas de agentes, auditar solo por usuario humano no es suficiente. También necesitas el contexto del cliente, el agente, la ejecución del modelo o flujo de trabajo y la tarea.

Una arquitectura práctica

Para una aplicación web seria con MCP y agentes de flujos de trabajo, yo empezaría aquí:

                    +----------------------+
                    | Auth0                |
                    | - Login              |
                    | - CIMD registration  |
                    | - Token issuance     |
                    | - OBO exchange       |
                    +----------+-----------+
                               |
                               v
+-------------+       +--------+---------+       +----------------+
| Web / Agent | ----> | MCP Gateway      | ----> | Internal APIs  |
| Client      |       | - JWT validation |       | - Business ops |
| CIMD URL    |       | - Scope checks   |       | - Data access  |
+-------------+       | - Tool policy    |       +--------+-------+
                      +--------+---------+                |
                               |                          |
                               v                          v
                      +--------+---------+       +----------------+
                      | Authorization    |       | Audit / SIEM   |
                      | - FGA/RBAC/ABAC  |       | - user         |
                      | - task policy    |       | - client       |
                      | - approval gates |       | - agent/task   |
                      +------------------+       +----------------+

El gateway MCP se convierte en el punto de control seguro. No necesita conocer por sí mismo todas las reglas de negocio, pero sí debe hacer cumplir la regla de que cada llamada a una herramienta tenga una identidad, un token, un scope, un recurso y una decisión.

Preguntas de producto que vale la pena hacer

Para los PM y líderes de ingeniería, la implementación es solo la mitad del diseño.

Pregúntate:

¿Qué acciones puede realizar un agente sin avisar?
¿Qué acciones requieren el consentimiento del usuario una sola vez?
¿Qué acciones requieren aprobación cada vez?
¿Qué APIs posteriores necesitan tokens vinculados al usuario?
¿Qué acciones son reversibles?
¿Qué acciones necesitan exportaciones de auditoría para clientes empresariales?
¿Qué clientes necesitan listas de clientes MCP aprobados a nivel de tenant?
¿Qué debería pasar cuando cambia un documento de metadatos de cliente?

Estas preguntas moldean la experiencia de usuario más que los detalles de OAuth.

Brechas y aspectos pendientes

Todavía hay áreas en las que los equipos necesitan diseñar con cuidado.

El soporte actual de CIMD en Auth0 requiere registro manual: un administrador del tenant importa y aprueba la URL de CIMD. Eso es bueno para mantener el control, pero no es lo mismo que aceptar automáticamente cualquier cliente desconocido.

La documentación de Auth0 también señala limitaciones actuales y trabajo futuro en torno al soporte de Organizations para aplicaciones de terceros y los límites de tasa para clientes CIMD.

CIMD por sí solo no resuelve por completo la suplantación de clientes de escritorio o localhost. La especificación MCP señala los riesgos de las redirecciones a localhost, y el ecosistema en general aún explora declaraciones de software y mecanismos de atestación de plataforma más sólidos.

La identidad del agente sigue siendo, en parte, un problema de arquitectura de la aplicación. OAuth puede identificar al usuario y al cliente. Tu orquestador aún necesita un modelo claro para la identidad del agente, la identidad de la tarea, las aprobaciones y los registros de auditoría.

Modelo mental final

Piensa en Auth0 CIMD como la etiqueta de entrada de un cliente OAuth en un ecosistema dinámico de agentes.

Dice:

This is the client.
Here is where its metadata lives.
Here are its redirect URIs and auth method.
Here is what users and admins should see before trusting it.

Auth0 Auth for MCP proporciona la infraestructura de identidad alrededor de ese cliente:

discover -> authorize -> issue token -> call MCP -> exchange token -> call API

Tu aplicación aporta las medidas de seguridad del producto:

permissions -> approvals -> audit -> least privilege -> human accountability

Esa combinación es lo que hace que las aplicaciones basadas en agentes empiecen a parecer menos demos y más sistemas reales.

Auth0 CIMD para aplicaciones modernas, MCP y flujos de trabajo con agentes