WorkOS presentó auth.md, una especificación que define un archivo Markdown público en la raíz del dominio para que agentes de IA descubran cómo registrarse, qué scopes solicitar y cómo se emiten, auditan y revocan credenciales sin intervención humana.
WorkOS lanzó auth.md, una especificación que propone colocar un archivo Markdown público (por ejemplo https://service.com/auth.md) para que agentes de IA y humanos encuentren de forma legible cómo registrarse en una aplicación y obtener credenciales ligadas a un usuario real sin que este complete formularios manuales. La idea central es facilitar el descubrimiento automatizado de capacidades y endpoints de registro, resolviendo una brecha en aplicaciones que hoy asumen interacción humana.
Técnicamente, el protocolo usa un descubrimiento en dos saltos: el Metadato de Recurso Protegido (PRM) vive en /.well-known/oauth — protected-resource y referencia al Authorization Server en /.well-known/oauth — authorization-server. En el Authorization Server un bloque agent_auth describe campos como register_uri, claim_uri, revocation_uri e identity_types_supported. El auth.md actúa como pieza en prosa que apunta a esa ruta y complementa la información técnica para agentes y operadores.
Para iniciar el descubrimiento automáticamente, la especificación exige que la API, ante un 401, devuelva un encabezado WWW — Authenticate: Bearer resource_metadata="..." que incluya la referencia al PRM; con ello el agente puede localizar los metadatos y ejecutar el flujo de registro adecuado sin intervención manual.
El documento aborda un problema de mercado concreto: muchas aplicaciones web suponen la presencia de un humano en un navegador (clics, formularios, verificación por email) y, como alternativa, equipos suelen entregar a agentes claves API o tokens de sesión — credenciales que a menudo carecen de scopes, son difíciles de auditar por sesión y complicadas de revocar de forma selectiva. auth.md se plantea como una alternativa estructurada para ese vacío operativo.
En el flujo verificado por el proveedor del agente, el proveedor de identidad del agente (por ejemplo OpenAI, Anthropic o Cursor) emite un ID denominado JAG que el agente envía por POST a /agent/auth. La aplicación decodifica el encabezado JAG para obtener kid y alg, consulta la lista de emisores de confianza, descarga el JWKS del proveedor, verifica la firma y valida claims como aud, exp, iat, jti y client_id. Si la verificación es correcta, la aplicación entrega credenciales de forma síncrona sin OTP ni interacción humana y crea un registro de delegación identificado por (iss, sub, aud).
El proveedor puede revocar esa delegación enviando un logout token al revocation_uri. La especificación señala expresamente que los access tokens resultantes no deben incluir refresh token; para extender acceso, el agente debe presentar un JAG fresco.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
