OAuth pour serveurs MCP : les trois changements de 2026-07-28

La révision MCP 2026-07-28 ne touche pas qu'au transport. Elle durcit aussi l'autorisation, avec trois changements motivés par une observation simple : dans la vraie vie, un client MCP parle à beaucoup de serveurs, souvent à des dizaines. Ce n'est pas la forme de déploiement pour laquelle OAuth a été pensé au départ.

Les trois changements sont petits en volume de code et importants en conséquences. Aucun n'est visible tant que rien ne va mal.

Pourquoi la forme du déploiement change tout

Une application web classique parle à un serveur d'autorisation qu'elle connaît. Un client MCP, lui, découvre des serveurs qu'il n'a jamais vus, chacun avec son propre serveur d'autorisation, et il stocke des credentials pour tous.

Cette asymétrie ouvre une classe d'attaques : faire croire au client qu'il parle au serveur d'autorisation A alors qu'il parle à B, ou réutiliser des credentials émis par l'un auprès de l'autre. Les trois changements ferment ces portes.

1. Le paramètre iss doit être validé

Le serveur d'autorisation devrait inclure le paramètre iss dans ses réponses d'autorisation. Et le client doit valider ce iss contre l'issuer qu'il a enregistré, avant d'échanger le code d'autorisation.

C'est la protection contre la substitution de serveur d'autorisation. Sans cette vérification, un client qui a lancé un flux vers A peut recevoir une réponse fabriquée par B et échanger son code au mauvais endroit.

Ce qu'il faut vérifier chez toi :

• Si tu opères un serveur d'autorisation, est-ce qu'il émet bien iss ?
• Si tu as écrit un client MCP, est-ce qu'il valide iss avant l'échange de code, et pas après ?
• Est-ce que l'échec de validation est traité comme un rejet, et pas comme un avertissement ?

Ce dernier point est celui qu'on rate. Une vérification qui logge et continue ne protège de rien.

2. application_type doit être précisé à l'enregistrement

Le client doit indiquer un application_type approprié quand il s'enregistre, pour éviter les conflits de redirect URI côté OpenID Connect.

Le problème qu'il règle est concret. OIDC applique des contraintes différentes selon qu'un client est natif ou web, notamment sur les URI de redirection autorisées (localhost, schémas personnalisés, HTTPS strict). Un client MCP en ligne de commande et une application web n'ont pas les mêmes besoins, et le serveur d'autorisation ne peut pas deviner.

Si tu construis un client, déclare le bon type. Si tu opères un serveur d'autorisation, décide ce que tu fais des enregistrements qui ne le précisent pas.

3. Les credentials sont liés à leur émetteur

Les credentials d'un client sont liés au serveur d'autorisation qui les a émis. Concrètement : ils doivent être stockés indexés par issuer, et le client doit se réenregistrer si le serveur d'autorisation change.

C'est la règle la plus facile à violer sans le vouloir, parce que beaucoup de clients stockent un client_id et un client_secret dans une config globale, comme s'il n'y en avait qu'un. Ça marche tant qu'on parle à un seul serveur. À partir de deux, on réutilise des credentials là où ils n'ont pas cours, et le comportement dépend de la tolérance du serveur d'en face.

La correction est structurelle : ta clé de stockage n'est pas le nom du service, c'est l'issuer.

Et le Dynamic Client Registration

En plus des trois, le Dynamic Client Registration OAuth 2.0 est formellement déprécié comme mécanisme d'enregistrement, au profit des Client ID Metadata Documents.

Il continue de fonctionner pour la compatibilité, mais il est sur une horloge. C'est un chantier distinct, traité dans son propre article.

Ce que ça change si tu opères un serveur MCP

Beaucoup d'équipes lisent ces changements comme « c'est le problème des clients ». En partie oui. Mais trois choses te concernent directement :

Ton serveur d'autorisation doit émettre iss****. Si tu délègues à un fournisseur d'identité, vérifie qu'il le fait dans la configuration que tu utilises, pas seulement en théorie.

Tes clients maison sont des clients MCP. Le script interne qui appelle ton propre serveur tombe sous les mêmes règles, et il est presque toujours le plus laxiste du lot.

Ta documentation d'intégration doit suivre. Si tu expliques à tes clients comment se connecter, tes exemples de code deviennent la référence qu'ils copient. Un exemple qui ne valide pas iss propage la faille.

Les erreurs les plus fréquentes

Valider après l'échange de code. La vérification doit avoir lieu avant, sinon elle ne protège plus rien.

Un seul jeu de credentials pour tous les serveurs. Voir le point 3. C'est le défaut par facilité, pas par décision.

Traiter l'autorisation comme un sujet réglé une fois. Le protocole a une politique de dépréciation et une suite de conformité maintenant. La partie auth est celle qui bougera le plus dans les prochaines révisions.

Confondre authentification et autorisation par outil. Savoir qui appelle ne dit pas ce qu'il a le droit d'appeler. Un token valide qui donne accès à tous les outils est le défaut le plus répandu en production.

FAQ

Est-ce que je dois tout refaire ?

Non. Ces trois changements sont des vérifications ajoutées, pas une nouvelle architecture. Compte quelques jours si ta chaîne OAuth est propre, plus si tes credentials sont stockés globalement.

Je passe par un fournisseur d'identité, suis-je couvert ?

Partiellement. Le fournisseur gère l'émission, mais la validation côté client et le stockage indexé par issuer restent chez toi.

Est-ce que ça bloque ma soumission à un annuaire de connecteurs ?

Une chaîne OAuth non conforme est un des motifs de refus les plus classiques. Fais cette mise à niveau avant de préparer un dossier, pas après.

Faire vérifier ta chaîne OAuth

L'audit couvre les trois points, plus le stockage des credentials, la portée des scopes et la révocation par client. Sous 24 heures ouvrées, tu as le rapport et le chiffrage.

Prêt à faire le point ? Faire auditer mon serveur MCP →

Lectures liées

• Dynamic Client Registration déprécié : passer aux Client ID Metadata Documents
• Les 8 failles qu'on retrouve dans presque tous les serveurs MCP en prod
• Migrer un serveur MCP vers la spec 2026-07-28 : le guide complet