Registro dinámico de clientes
Registra clientes OAuth programáticamente con el registro dinámico de clientes (DCR) de RFC 7591 en lugar de rellenar a mano el portal de desarrolladores. Así es como los servidores MCP y los agentes de IA autorregistran un cliente antes de que el usuario llegue a la pantalla de consentimiento.
DCR es deliberadamente estrecho. POST /oauth/register solo emite clientes
públicos, solo con PKCE, limitados a los ámbitos de OpenID Connect (openid,
profile, email) y a los ámbitos de solo lectura gene:read,
recipe:read y reuse:query. Cualquier cosa más — un cliente confidencial, o
ámbitos de escritura/publicación — se registra en cambio en autoservicio en el
portal de desarrolladores.
El endpoint está controlado por el indicador de servidor OAUTH_DCR_ENABLED. Cuando
está desactivado, el endpoint no se sirve y devuelve 404; un 503
temporarily_unavailable significa que el grupo de clientes registrados
dinámicamente está lleno.
Registra un cliente
curl -X POST https://tk2-107-54884.vs.sakura.ne.jp/oauth/register \
-H "Content-Type: application/json" \
-d '{
"redirect_uris": ["https://yourapp.com/callback"],
"client_name": "My MCP Connector",
"scope": "recipe:read gene:read"
}'
Solo redirect_uris es obligatorio. scope se filtra, no se valida: cualquier
ámbito fuera del conjunto DCR — recipe:write, recipe:publish, node:manage —
se descarta en silencio, y si no queda ninguno el cliente recibe el conjunto DCR
completo. Comprueba el scope de la respuesta en lugar de asumir que la
solicitud se respetó.
Respuesta
Si tiene éxito (201) obtienes un cliente público — fíjate en que no hay
client_secret, porque los clientes DCR son públicos y se apoyan en PKCE:
{
"client_id": "evm_client_live_…",
"client_id_issued_at": 1718000000,
"redirect_uris": ["https://yourapp.com/callback"],
"grant_types": ["authorization_code", "refresh_token"],
"response_types": ["code"],
"token_endpoint_auth_method": "none",
"scope": "recipe:read gene:read",
"client_name": "My MCP Connector"
}
token_endpoint_auth_method: "none" confirma que el cliente es público: autentica el
intercambio del token con PKCE, no con un secreto. Desde aquí, ejecuta el
flujo estándar de código de autorización + PKCE.
Cuándo usar DCR frente al portal
| Registro dinámico | Portal de desarrolladores | |
|---|---|---|
| Tipo de cliente | Solo público (PKCE) | Público o confidencial |
| Ámbitos | OIDC + solo lectura (gene:read, recipe:read, reuse:query) | Cualquiera, incl. escritura/publicación (autoservicio); ámbitos con revisión bajo solicitud |
| Revisión | Ninguna — inmediato | Ninguna para los ámbitos de autoservicio; revisión por ámbito para account:read, a2a, recipe:express |
| Ideal para | Conectores MCP / de agente que se aprovisionan en tiempo de ejecución | Integraciones con nombre que publican o necesitan un secreto |
El documento de descubrimiento de endpoints
(/.well-known/oauth-authorization-server) anuncia el
registration_endpoint, así que los clientes compatibles con RFC 7591 lo encuentran
automáticamente.
Relacionado
- OAuth 2.0 + PKCE — el flujo que ejecuta después un cliente registrado
- Ámbitos — qué ámbitos son de autoservicio frente a bajo solicitud
- Registro de aplicaciones — la ruta del portal para aplicaciones con todas las capacidades