Contexte et problème n²

Les plateformes d’automatisation comme Zapier offrent des milliers de connecteurs, mais chaque paire d’applications nécessite un enregistrement OAuth distinct. Cette multiplication conduit à un problème de complexité quadratique (n²) : chaque nouvelle intégration impose de créer manuellement un client OAuth, processus qui peut durer de cinq minutes à plusieurs heures selon les exigences du portail développeur.

Enregistrement dynamique des clients OAuth (DCR)

Le Dynamic Client Registration (DCR) ajoute une extension au protocole OAuth qui permet à une application de provisionner automatiquement un client OAuth auprès d’un serveur d’autorisation. Ainsi, l’application ne dépend plus d’une intervention humaine pour chaque nouveau partenaire. Val Town a intégré DCR dans son serveur MCP, ce qui permet à n’importe quel service compatible d’enregistrer un client au moment de la première connexion utilisateur.

@jsxImportSource https://esm.sh/hono/jsx
import { Hono } from "https://esm.sh/hono";
import { getOAuthUserData, oauthMiddleware } from "https://esm.town/v/std/oauth/middleware.ts";
const app = new Hono();
app.get("/", async (c) => {
  const session = await getOAuthUserData(c.req.raw);
  return c.html(
    
      
        {session?.user
          ? 
Logged in as {session.user.username}

          : Log in}
      
    ,
  );
});
export default oauthMiddleware(app.fetch);

Le code ci‑dessus montre comment ajouter « Login with Val Town » en deux lignes : le middleware crée le client OAuth via DCR dès que le premier utilisateur déclenche le flux d’autorisation.

Documents de métadonnées d’ID client (CIMD)

Le Client ID Metadata Document (CIMD) supprime même l’étape d’enregistrement préalable. Un service publie un fichier JSON accessible via .well-known/oauth-authorization-server. Exemple tiré de Notion :

{
  "issuer": "https://mcp.notion.com",
  "authorization_endpoint": "https://mcp.notion.com/authorize",
  "token_endpoint": "https://mcp.notion.com/token",
  "registration_endpoint": "https://mcp.notion.com/register",
  "scopes_supported": ["default"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code","refresh_token","urn:ietf:params:oauth:grant-type:jwt-bearer"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic","client_secret_post","none"],
  "client_id_metadata_document_supported": true
}

Tout client qui consomme ce document peut initier immédiatement un flux OAuth avec Notion, même s’il ne l’a jamais rencontré auparavant.

Limites et défis d’implémentation

Première difficulté : de nombreux serveurs déclarent un endpoint DCR mais imposent une pré‑inscription dans un catalogue. L’appel vers Google Ads renvoie l’erreur « redirect host not in platform catalog », ce qui bloque l’enregistrement totalement dynamique.

Deuxième problème concerne la distinction entre MCP (Message‑Based Communication Protocol) et les API REST classiques. DCR/CIMD fonctionnent souvent uniquement sur le canal MCP, ce qui ne garantit pas l’accès aux points d’exécution REST d’un service comme Stripe. Les développeurs doivent donc gérer deux modèles d’autorisation : l’un pour les flux MCP, l’autre pour les API REST, chaque modèle ayant ses propres exigences de stabilité et de versionnage.

Malgré ces obstacles, des milliers d’applications supportent déjà DCR et plusieurs centaines offrent CIMD. Val Town a démontré la viabilité du concept avec une instance contenant plus de 3 600 connecteurs, tous activés sans configuration manuelle de client OAuth.