WorkOS a sorti auth.md cette semaine — une spec ouverte plus un artifact fichier concret pour le problème que presque chaque shop d'agent bricolait à la main : comment un agent prouve qu'il agit pour le compte de l'utilisateur X, avec des credentials user-scoped, révocables, et qui ne sont pas une clé API brute dans des variables d'environnement. La forme : un petit fichier Markdown qu'une application publie à la racine de son service (sert de documentation pour les développeurs humains ET d'artifact runtime que les agents peuvent lire programmatiquement), plus des extensions de métadonnées OAuth 2.0. Pour qui déploie des agents en production qui ont besoin d'appeler des API tierces pour le compte d'un utilisateur, c'est la spec qui adresse le bon problème.
La discovery est une chaîne de métadonnées deux-hops. Un agent hit `/.well-known/oauth-protected-resource` (Protected Resource Metadata) pour trouver l'authorization server, puis fetch `/.well-known/oauth-authorization-server` qui contient un nouveau bloc `agent_auth` avec quatre URIs : `register_uri`, `claim_uri`, `revocation_uri`, et `identity_types_supported`. Le nouveau grant type c'est ID-JAG (Identity-scoped JSON Authorization Grant) per RFC 9728 — les agent identity providers attestent l'identité utilisateur via des JWTs signés, l'authorization server valide l'assertion, retourne des credentials scopés. Une réponse 401 sur un endpoint protégé inclut `WWW-Authenticate: Bearer resource_metadata="..."` pour bootstrap l'agent dans la chaîne de discovery sans config préalable. OpenAI, Anthropic et Cursor sont cités comme identity providers potentiels ; la spec ne requiert aucun vendor unique.
La distinction d'avec le RFC 7591 Dynamic Client Registration compte et la spec est explicite là-dessus. RFC 7591 laisse un client s'enregistrer auprès d'un authorization server — utile, mais le client s'authentifie *comme lui-même*. auth.md résout un problème différent : l'agent s'authentifie *comme l'utilisateur*, au nom de l'utilisateur, avec l'authorization server comprenant cette distinction et émettant des credentials user-scoped révocables. C'est le bon primitif pour le monde agent-loop : un agent qui appelle `send_email` devrait agir avec les permissions email de l'utilisateur, pas avec des permissions globales "je suis le service agent", et l'utilisateur devrait pouvoir révoquer l'accès de cet agent spécifique sans rotater ses propres credentials. Aujourd'hui la plupart des produits agent soit demandent à l'utilisateur de coller des clés API brutes (insécure, non-révocable par-agent) soit roulent tout via la propre auth du vendor agent (lock-in). auth.md est le middle standardisé.
Lundi matin : si tu shippes un agent qui doit appeler des API tierces au nom d'utilisateurs, lis la spec à github.com/workos/auth.md et check si ton auth provider (Auth0, Okta, custom) a une roadmap vers le support ID-JAG. Le gap honnête c'est le statut d'implémentation — early access seulement, pas de serveurs production widespread, et l'article note que les MCP servers ou les appels API LLM bruts ne peuvent typiquement pas participer au flow agent-verified à ce stade. La compatibilité avec les libraries OAuth existantes n'est pas explicitement adressée dans le release ; attends-toi à des rough edges. Mais le call architectural est sain : c'est le user-side du même problème que résout le bridge IAM-OAuth du serveur AWS MCP côté ressource, et la stack agent-infra a besoin des deux. WorkOS est tôt sur la spec ; la question c'est si OpenAI, Anthropic et les cloud providers shippent de l'interop en mois ou en trimestres.