auth.md — un protocole ouvert pour permettre aux agents d’inscrire les utilisateurs à leur place

• Standard de fichier auth.md hébergé par chaque service à la racine de son domaine
• Il indique à un agent comment enregistrer un utilisateur en son nom, ce qui permet à l’agent d’inscrire l’utilisateur sans formulaire d’inscription séparé
• Le fichier inclut les flows pris en charge, les scopes existants et la méthode d’inscription au service
• Il se compose de trois acteurs
  • agent : entité qui agit au nom de l’utilisateur
  • agent provider : IdP qui émet l’assertion d’identité ID-JAG
  • service : entité qui accepte l’assertion et émet des identifiants
• L’agent récupère auth.md, choisit un flow pris en charge, puis présente une verified identity assertion ou exécute une code confirmation claim côté utilisateur
• Le mode d’inscription est présenté commercialement en deux catégories, mais il y en a en pratique trois côté implémentation, y compris l’anonymous
  • Agent verified : l’IdP de l’agent garantit l’utilisateur, sans intervention humaine
  • User claimed : pas besoin de provider ; après connexion, l’utilisateur confirme le code affiché par l’agent. Utilise une claim ceremony de style RFC 8628 (méthode device flow)
  • Anonymous Registration : l’agent commence avec un pre-claim scope, puis est promu vers un post-claim token lorsque l’utilisateur revendique la propriété
  • La plupart des applications prennent en charge les deux approches, et l’agent choisit selon la situation
• Un scoped access token lié à l’utilisateur est émis pour l’agent, avec une courte durée de vie et possibilité de révocation
• Émis au-dessus du standard OAuth, ce qui permet de réutiliser tel quel le mécanisme d’authentification API existant
  • Émission d’ID-JAG → échange contre un access_token via le grant JWT-bearer RFC 7523, avec découverte via /.well-known/oauth-authorization-server
• Rédigé par WorkOS, mais il s’agit d’un protocole ouvert non dépendant de l’infrastructure WorkOS
  • Combine des standards OAuth existants (Protected Resource Metadata, ID-JAG) pour permettre de publier et lire sans compte
• Les applications/services peuvent contrôler directement quels flows accepter et quels identifiants émettre
• En plus de la spécification, des implémentations d’exemple côté agent provider et service ainsi qu’un fichier AUTH.md jouant le rôle de skill manifest sont fournis pour pouvoir l’essayer réellement
• Plusieurs services l’ont déjà adopté, dont Cloudflare, Firecrawl, Resend et monday.com
• Licence MIT

[bichi]

Pourquoi ce n’est pas AUTH.md ?

[laeyoung]

L’auth.md de Firecrawl et de Resend.

Cloudflare apparaît comme le premier cas d’usage sur la page de présentation du protocole, mais quand on clique dessus, on tombe sur not found :(.