Architecture, Security · · per Michael Wybraniec

Serveurs MCP comme Serveurs de Ressources OAuth : Une Approche Simplifiée

Traiter le serveur MCP comme un serveur de ressources OAuth plutôt qu'un serveur d'autorisation permet une architecture plus simple, sans état et adaptée aux entreprises.

Retour aux articles | Architecture MCP | Sécurité MCP | RFC 8693 Token Exchange

L'architecture d'autorisation du Model Context Protocol (MCP) peut être considérablement simplifiée en traitant les serveurs MCP comme des serveurs de ressources OAuth plutôt que comme des serveurs d'autorisation. Cette approche révolutionnaire, proposée par dasiths dans la discussion GitHub, permet aux développeurs de tirer parti des solutions d'identité existantes comme Okta, Auth0, Microsoft Entra ID tout en réduisant la complexité d'implémentation et en améliorant l'adoption en entreprise.

Le Problème avec l'Approche Actuelle

⤴

L'implémentation actuelle du brouillon d'autorisation MCP traite chaque serveur MCP comme un serveur d'autorisation OAuth. Cela signifie que chaque développeur de serveur MCP doit implémenter conformément aux spécifications :

  • RFC 8414 - OAuth 2.0 Authorization Server Metadata
  • RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol
  • Les endpoints d'autorisation et de tokens
  • La gestion des sessions utilisateurs Cette approche crée une complexité inutile et constitue un obstacle majeur à l'adoption, comme l'a souligné gao-sun qui a testé cette implémentation avec Logto, Keycloak et Auth0.

La Solution : Serveur de Ressources OAuth

⤴

En traitant le serveur MCP comme un serveur de ressources OAuth conformément au RFC 9728 - OAuth 2.0 Protected Resource Metadata, nous déléguons l'authentification et l'autorisation à des fournisseurs d'identité existants. Cette approche transforme le serveur MCP en un service sans état en ce qui concerne les préoccupations d'authentification, utilisant le RFC 8693 Token Exchange pour les scénarios de délégation.

Selon la spécification officielle MCP, les serveurs MCP DOIVENT implémenter OAuth 2.0 Protected Resource Metadata pour indiquer l'emplacement des serveurs d'autorisation via l'en-tête WWW-Authenticate lors du retour d'un 401 Unauthorized.

Diagramme 1 : Flux de découverte et d'autorisation MCP avec serveur de ressources OAuth

Ce diagramme illustre le processus complet de découverte des métadonnées et d'autorisation entre un client MCP, un serveur MCP agissant comme serveur de ressources OAuth, et un serveur d'autorisation externe. Le flux commence par une requête non autorisée et se termine par une communication MCP sécurisée avec un token d'accès valide.

sequenceDiagram
    participant C as Client MCP
    participant M as Serveur MCP (Serveur de Ressources)
    participant A as Serveur d'Autorisation

    C->>M: Requête MCP sans token
    M-->>C: HTTP 401 Unauthorized avec en-tête WWW-Authenticate
    Note over C: Extraire resource_metadata<br />du WWW-Authenticate

    C->>M: GET /.well-known/oauth-protected-resource
    M-->>C: Métadonnées de ressource avec URL serveur d'autorisation
    Note over C: Valider métadonnées RS,<br />construire URL métadonnées AS

    C->>A: GET /.well-known/oauth-authorization-server
    A-->>C: Métadonnées serveur d'autorisation

    Note over C,A: Flux d'autorisation OAuth 2.1 se déroule ici

    C->>A: Requête de token
    A-->>C: Token d'accès

    C->>M: Requête MCP avec token d'accès
    M-->>C: Réponse MCP
    Note over C,M: Communication MCP continue avec token valide

Avantages de Cette Approche

⤴

🏢 Adoption Entreprise

Cette approche augmente considérablement l'adoptabilité de MCP dans les scénarios d'entreprise où des serveurs d'autorisation OAuth sont déjà déployés. Les organisations peuvent :

  • Utiliser leurs solutions d'identité existantes
  • Appliquer leurs politiques de sécurité établies
  • Intégrer MCP dans leur architecture de sécurité actuelle

⚡ Réduction de Complexité

Les développeurs de serveurs MCP n'ont plus besoin de :

  • Implémenter des flux d'autorisation complexes
  • Gérer les sessions et tokens liés
  • Maintenir des bases de données d'utilisateurs

🔒 Sécurité Renforcée

  • Réduction de la surface d'attaque en cas de vulnérabilité
  • Architecture sans état pour les préoccupations d'auth
  • Possibilité d'utiliser des flux d'échange de tokens pour agir au nom de l'utilisateur

🔄 Flexibilité Client

Les clients MCP peuvent tirer parti de n'importe quel flux OAuth supporté pour récupérer un token :

  • Client credentials
  • Authorization code
  • Device code
  • Token exchange

Scénario d'Exemple : Échange de Tokens

⤴

Considérons une organisation avec une multitude d'APIs REST développées au fil des années, comme mentionné par dasiths dans sa proposition. Ces APIs sont protégées par l'authentification JWT bearer conformément au RFC 6750 et disposent de serveurs d'autorisation OAuth existants (Okta, Auth0, Microsoft Entra ID, Keycloak).

Le chemin le plus simple pour adopter MCP serait de tirer parti de leur solution d'auth existante et de traiter le serveur MCP comme un simple service de niveau intermédiaire qui doit consommer leurs APIs existantes en utilisant le Token Exchange Flow du RFC 8693.

// Exemple d'implémentation côté serveur MCP inspirée de MCP Auth par gao-sun
class MCPResourceServer {
  async handleRequest(request: MCPRequest, accessToken: string) {
    // 1. Valider le token avec le serveur d'autorisation (RFC 7662 Token Introspection)
    const validation = await this.validateToken(accessToken);
    
    if (!validation.valid) {
      throw new UnauthorizedError();
    }
    
    // 2. Échange de token pour accéder aux APIs internes (RFC 8693)
    const exchangedToken = await this.exchangeToken(
      accessToken, 
      'urn:ietf:params:oauth:token-type:access_token',
      'https://api.internal.company.com'
    );
    
    // 3. Appel à l'API avec le token échangé
    return await this.callInternalAPI(exchangedToken);
  }
  
  // Métadonnées de ressource protégée (RFC 9728) - Endpoint /.well-known/oauth-protected-resource
  async getResourceMetadata() {
    return {
      "authorization_servers": ["https://auth.company.com"],
      "scopes_supported": ["mcp:read", "mcp:write", "mcp:admin"],
      "bearer_methods_supported": ["header"],
      "resource_documentation": "https://docs.company.com/mcp-api"
    };
  }
  
  // Gestion de l'en-tête WWW-Authenticate selon la spécification MCP
  async handleUnauthorized(response: Response) {
    response.status = 401;
    response.headers.set('WWW-Authenticate', 
      'Bearer realm="MCP Server", resource_metadata="https://mcp.company.com/.well-known/oauth-protected-resource"'
    );
    response.headers.set('MCP-Protocol-Version', '2024-11-05');
    return response;
  }
}

Types de Grants OAuth Supportés

⤴

Selon le type de client et le cas d'usage, différents grants OAuth peuvent être utilisés avec cette approche :

Type de GrantType de Client / Cas d'Usage
Authorization CodeApplications web traditionnelles avec backend et applications natives (mobile/desktop) pour SSO via navigateur système
Client CredentialsClients comme services web agissant en leur propre nom
Device CodeAppareils sans navigateur ou avec saisie contrainte (Smart TV, console média, imprimante, etc.)
Token ExchangeApplications et services obtenant un token d'accès dans des scénarios de délégation et d'impersonation
JWT BearerClient possédant un JWT d'un domaine de sécurité l'échangeant contre un token OAuth 2.0 dans un autre domaine

Flux d'Autorisation Complet

⤴

Diagramme 2 : Flux d'autorisation OAuth 2.1 complet avec interaction utilisateur

Ce diagramme détaille le processus d'autorisation OAuth 2.1 incluant l'interaction avec l'agent utilisateur (navigateur). Il montre comment un client MCP obtient l'autorisation de l'utilisateur via le navigateur, utilise PKCE pour la sécurité, et échange le code d'autorisation contre un token d'accès pour établir une communication sécurisée avec le serveur MCP.

sequenceDiagram
    participant B as Agent Utilisateur (Navigateur)
    participant C as Client MCP
    participant M as Serveur MCP (Serveur de Ressources)
    participant A as Serveur d'Autorisation

    C->>M: Requête MCP sans token
    M->>C: HTTP 401 Unauthorized avec en-tête WWW-Authenticate
    Note over C: Extraire l'URL resource_metadata du WWW-Authenticate

    C->>A: GET /.well-known/oauth-authorization-server
    A->>C: Réponse métadonnées serveur d'autorisation

    alt Enregistrement client dynamique
        C->>A: POST /register
        A->>C: Identifiants Client
    end

    Note over C: Générer paramètres PKCE
    C->>B: Ouvrir navigateur avec URL d'autorisation + code_challenge
    B->>A: Requête d'autorisation
    Note over A: L'utilisateur autorise
    A->>B: Redirection vers callback avec code d'autorisation
    B->>C: Callback code d'autorisation
    C->>A: Requête token + code_verifier
    A->>C: Token d'accès (+ token de rafraîchissement)
    C->>M: Requête MCP avec token d'accès
    M-->>C: Réponse MCP

Considérations de Sécurité

⤴

🔐 Bonnes Pratiques

  • PKCE requis pour tous les clients et serveurs d'autorisation MCP
  • Stockage sécurisé des tokens suivant les meilleures pratiques OAuth 2.0
  • Validation des URI de redirection pour prévenir les vulnérabilités de redirection ouverte
  • HTTPS obligatoire pour tous les endpoints d'autorisation

⚠️ Gestion d'Erreurs

Code de StatutDescriptionUsage
401Non autoriséAutorisation requise ou token invalide
403InterditScopes invalides ou permissions insuffisantes
400Requête incorrecteRequête d'autorisation malformée

Impact sur l'Écosystème MCP

⤴

Cette approche révolutionnaire simplifie considérablement l'intégration des serveurs d'autorisation, permettant de se connecter directement aux fournisseurs comme Okta, Auth0, Microsoft Entra ID, Keycloak et autres sans avoir à développer un serveur d'autorisation from scratch.

Moins de code boilerplate. Plus de développement. MCP devient plus adapté aux entreprises.

Comme l'a annoncé dasiths : "Big thank you to everyone who spent their valuable time providing input, reviewing the PR and waiting patiently while this change was discussed over the past 4 weeks. It was a massive community effort."

Cette nouvelle spécification est maintenant disponible dans le draft officiel MCP - Section Authorization et incluse dans la spécification du 18 juin 2025.

Exigences de la Spécification MCP

Selon la spécification officielle, les serveurs MCP agissant comme serveurs de ressources DOIVENT :

  1. Implémenter OAuth 2.0 Protected Resource Metadata (RFC9728)
  2. Utiliser l'en-tête WWW-Authenticate lors du retour d'un 401 Unauthorized
  3. Supporter l'endpoint /.well-known/oauth-protected-resource
  4. Inclure le champ authorization_servers avec au moins un serveur d'autorisation

Les clients MCP DOIVENT :

  1. Parser les en-têtes WWW-Authenticate et répondre aux réponses HTTP 401
  2. Suivre le protocole OAuth 2.0 Authorization Server Metadata (RFC8414)
  3. Inclure l'en-tête MCP-Protocol-Version dans les requêtes

Mises à jour des SDKs en cours :

  • Python SDK - Support pour la nouvelle spécification d'autorisation
  • C# SDK - Intégration ASP.NET Core native AuthN/AuthZ
  • MCP Auth - Implémentation de référence par gao-sun
// Exemple de métadonnées de ressource protégée (RFC 9728)
{
  "authorization_servers": [
    "https://auth.company.com"
  ],
  "resource_metadata": {
    "resource": "https://mcp.company.com",
    "authorization_servers": ["https://auth.company.com"],
    "scopes_supported": ["mcp:read", "mcp:write", "mcp:admin"],
    "bearer_methods_supported": ["header"],
    "resource_documentation": "https://docs.company.com/mcp-api"
  }
}

// En-tête WWW-Authenticate pour découverte (RFC 9728)
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="MCP Server",
                  resource_metadata="https://mcp.company.com/.well-known/oauth-protected-resource"
MCP-Protocol-Version: 2024-11-05

Flux de Découverte Officiel MCP

Selon la spécification MCP 2.3.4, le processus de découverte suit ce flux précis :

  1. Client MCP fait une requête sans token
  2. Serveur MCP répond avec HTTP 401 et en-tête WWW-Authenticate
  3. Client extrait l'URL resource_metadata de l'en-tête
  4. Client récupère /.well-known/oauth-protected-resource du serveur MCP
  5. Client utilise ces métadonnées pour construire l'URL du serveur d'autorisation
  6. Client récupère /.well-known/oauth-authorization-server
  7. Flux OAuth 2.1 standard se déroule
  8. Communication MCP reprend avec le token valide

Cette approche, validée par gao-sun avec des tests sur Logto, Keycloak et Auth0, est maintenant la méthode recommandée dans l'écosystème MCP.

Conclusion

⤴

L'adoption de l'approche serveur de ressources OAuth pour les serveurs MCP marque un tournant décisif dans l'évolution de l'écosystème MCP vers une architecture plus mature et adaptée aux entreprises. Cette nouvelle spécification, fruit d'un effort communautaire de 4 semaines dirigé par dasiths et validé par gao-sun, transforme radicalement la façon dont nous concevons l'authentification et l'autorisation dans MCP.

Pourquoi agir maintenant ?

  • ✅ Spécification officialisée dans MCP 2.3.4 (18 juin 2025)
  • ✅ SDKs en cours de mise à jour (Python, C#, JavaScript)
  • ✅ Implémentations de référence disponibles (MCP Auth par gao-sun)
  • ✅ Support confirmé pour Okta, Auth0, Microsoft Entra ID, Keycloak

🚀 Prochaines Étapes Recommandées

  1. Explorez l'implémentation de référence : MCP Auth par gao-sun
  2. Consultez la spécification officielle : MCP Authorization Draft
  3. Testez avec votre fournisseur d'identité existant (Okta, Auth0, etc.)
  4. Rejoignez la discussion communautaire : GitHub Discussions

💡 Besoin d'Aide pour Implémenter MCP dans Votre Organisation ?

En tant qu'architecte spécialisé en MCP et OAuth, je peux vous accompagner dans :

  • Migration vers l'architecture serveur de ressources OAuth
  • Intégration avec vos systèmes d'identité existants
  • Formation de vos équipes sur les meilleures pratiques MCP
  • Audit de sécurité et architecture review

Contactez-moi pour discuter de votre projet MCP →

⤴

Michael Wybraniec

Michael Wybraniec

Freelance, MCP Servers, Full-Stack Development, Architecture

Contact

Agents MCP Tiny On-Premises : S'affranchir des Dépendances Cloud

Explorer comment exécuter des agents basés sur MCP entièrement on-premises en utilisant des LLMs locaux, en examinant les compromis entre la commodité du cloud et le contrôle local pour les déploiements d'IA en entreprise.

Pratiques de Sécurité pour MCP Utilisant JSON-RPC

Problèmes critiques de sécurité, meilleures solutions et outils pratiques pour des systèmes MCP robustes et sécurisés utilisant JSON-RPC.

Agents MCP Tiny On-Premises : S'affranchir des Dépendances Cloud

Explorer comment exécuter des agents basés sur MCP entièrement on-premises en utilisant des LLMs locaux, en examinant les compromis entre la commodité du cloud et le contrôle local pour les déploiements d'IA en entreprise.

Pratiques de Sécurité pour MCP Utilisant JSON-RPC

Problèmes critiques de sécurité, meilleures solutions et outils pratiques pour des systèmes MCP robustes et sécurisés utilisant JSON-RPC.