Une intégration OAuth peut fonctionner parfaitement en staging et échouer dès le premier essai en production.
Ce type d’incident est trompeur, car le code a déjà été testé.
Le flux d’authentification a été validé.
L’utilisateur a réussi à se connecter.
Le MCP server a accepté le token.
Tout semble donc prêt.
Mais OAuth ne dépend pas seulement du code.
Il dépend également de la configuration enregistrée auprès du provider, notamment des redirect URIs autorisées.
C’est précisément ce qui peut faire fonctionner une intégration dans un environnement et la faire échouer dans un autre.
Le scénario : tout fonctionne en staging
Le module décrit une intégration MCP authentifiée avec OAuth.
En staging, le parcours fonctionne de bout en bout.
Le développeur a enregistré une application OAuth pour :
staging.mycompany.com
L’intégration fonctionne correctement.
Le client MCP se connecte.
L’utilisateur s’authentifie.
Le provider OAuth renvoie correctement vers l’application.
L’équipe considère donc que le passage en production sera essentiellement une opération de déploiement.
Mais lors du premier essai en production, tous les sign-ins échouent.
Le symptôme : redirect URI mismatch
La revue post-déploiement fait apparaître une erreur précise :
redirect URI mismatch
Le problème n’est pas que l’utilisateur fournit un mauvais mot de passe.
Ce n’est pas non plus une défaillance du MCP server.
Le provider OAuth refuse le retour vers l’application.
Le développeur avait enregistré :
staging.mycompany.com
mais pas :
production.mycompany.com
Le provider considère donc l’URI de production comme non autorisée.
Pourquoi OAuth vérifie les redirect URIs
Dans un flux OAuth, après l’authentification de l’utilisateur, le provider doit savoir vers quelle adresse renvoyer le résultat du processus.
Cette adresse est une redirect URI.
Le principe conceptuel est :
Application
↓
OAuth provider
↓
User sign-in
↓
Authorization
↓
Redirect URI
↓
Application
Le provider ne doit pas rediriger vers n’importe quelle adresse.
Les redirect URIs autorisées sont donc enregistrées à l’avance.
Pourquoi cette protection est importante
Si un provider OAuth acceptait n’importe quelle URI de retour, un attaquant pourrait tenter de faire rediriger les tokens ou codes d’autorisation vers une adresse qu’il contrôle.
La liste des redirect URIs autorisées constitue donc une barrière de sécurité importante.
Le provider vérifie que l’URI utilisée lors du flux correspond à une URI autorisée pour l’application OAuth.
Si ce n’est pas le cas :
requested redirect URI
↓
not registered
↓
authentication rejected
Staging et production sont deux hosts différents
C’est le cœur du problème décrit dans le module.
Une configuration autorisant :
https://staging.mycompany.com/...
n’autorise pas automatiquement :
https://production.mycompany.com/...
Le fait que le même code tourne dans les deux environnements ne change rien.
Du point de vue du provider OAuth, il s’agit de destinations différentes.
Le document résume le problème ainsi :
OAuth redirect URIs are registered per host.
Il faut donc considérer l’enregistrement de la redirect URI comme une étape de déploiement à part entière.
Le faux raisonnement : « ça marche en staging, donc OAuth est validé »
Le test staging permet de vérifier beaucoup de choses :
- le code du flux OAuth ;
- l’intégration avec le provider ;
- la gestion du retour d’authentification ;
- la connexion entre le client et le service.
Mais il ne prouve pas que la configuration production existe.
On peut avoir :
Code OAuth
✓
Flow OAuth
✓
Provider integration
✓
Staging redirect URI
✓
Production redirect URI
✗
L’intégration est donc techniquement correcte tout en étant mal configurée pour le nouvel environnement.
Le dialogue qui révèle le problème
Le fichier fournit un échange particulièrement instructif.
Le security reviewer constate que chaque tentative de production échoue sur une erreur de redirect URI.
Le développeur explique qu’il avait enregistré l’application pour le domaine staging pendant le développement.
Le reviewer identifie immédiatement le problème :
staging registered
+
production not registered
=
production authentication failure
Le développeur demande alors s’il suffit d’ajouter l’URI de production.
La réponse est oui, mais une autre question apparaît immédiatement.
Faut-il utiliser la même OAuth app en staging et en production ?
Le reviewer soulève un second point :
Certains environnements enterprise demandent des OAuth app registrations séparées pour staging et production.
C’est une distinction importante.
Deux architectures sont possibles.
Une seule OAuth app
OAuth app
├── staging redirect URI
└── production redirect URI
Deux OAuth apps séparées
OAuth app staging
↓
staging environment
OAuth app production
↓
production environment
Le fichier indique que les environnements réglementés peuvent imposer la seconde approche dans leur politique de sécurité.
Pourquoi séparer staging et production ?
Le document ne développe pas tous les détails de cette politique, mais le principe est clair :
la séparation des environnements peut aussi s’appliquer à la configuration d’identité.
Cela permet de traiter staging et production comme deux contextes de sécurité différents.
Dans ce modèle :
Staging
→ identité OAuth dédiée
Production
→ identité OAuth dédiée
La question doit donc être vérifiée avant le déploiement.
Il ne faut pas supposer qu’une application OAuth unique est automatiquement conforme aux règles de l’organisation.
L’étape manquante n’était pas dans le code
C’est un aspect important du scénario.
L’intégration avait passé tous les tests staging.
Le problème production n’était donc pas un bug dans la logique applicative.
Il s’agissait d’une configuration externe liée au nouvel environnement.
C’est un bon exemple de la différence entre :
code correctness
et :
deployment correctness
Une intégration peut être correcte au niveau du code et échouer à cause d’une étape de configuration oubliée.
Ajouter OAuth à la deployment checklist
Le module insiste sur une bonne pratique simple :
Inclure l’enregistrement des redirect URIs dans la checklist de déploiement.
L’objectif est de ne pas découvrir ce type de dépendance lors du premier sign-in production.
Une checklist peut donc inclure :
OAuth deployment
[ ] Host production défini
[ ] Redirect URI production enregistrée
[ ] OAuth app registration vérifiée
[ ] Séparation staging/production vérifiée
[ ] Authentication testée sur le nouvel environnement
Le fichier insiste particulièrement sur les trois premiers points.
Le lien avec le principe « identifier les exigences avant le déploiement »
Cet incident rejoint une idée plus générale du module.
Les intégrations enterprise peuvent dépendre de nombreuses configurations extérieures au code :
- OAuth app registrations ;
- redirect URIs ;
- secret management ;
- managed settings ;
- audit logging ;
- data residency.
Si ces éléments ne sont examinés qu’au moment du passage en production, ils deviennent des causes de blocage tardif.
Le raisonnement attendu est donc :
avant déploiement
↓
identifier les dépendances externes
↓
configurer l'environnement
↓
tester
↓
déployer
et non :
déployer
↓
tester le premier utilisateur
↓
découvrir la configuration manquante
OAuth et identité utilisateur
Ce scénario doit également être replacé dans le raisonnement présenté dans l’article précédent.
OAuth est adapté aux services où l’identité de l’utilisateur fait partie du modèle d’autorisation.
On peut représenter la chaîne ainsi :
User
↓
OAuth
↓
Token
↓
MCP connection
↓
Remote service
La redirect URI intervient dans le processus permettant d’établir cette identité.
Elle fait donc partie intégrante du mécanisme d’authentification.
OAuth ne remplace pas la gestion des secrets
Le fait d’utiliser OAuth ne supprime pas les autres questions de sécurité.
Après authentification, un token est émis.
Le module rappelle que :
- le token doit être stocké correctement ;
- les credentials ne doivent pas voyager dans les fichiers de configuration ;
- les droits doivent rester limités ;
- l’environnement peut imposer des règles de configuration.
OAuth répond à la question :
Comment l’utilisateur autorise-t-il l’accès ?
Il ne répond pas à toutes les questions liées au cycle de vie des credentials ou à la gouvernance de l’intégration.
Ne pas confondre problème OAuth et problème de service credential
C’est également un bon point de révision.
Pour un service distant avec user identity :
OAuth
Pour un service distant avec service identity :
API key / service credential
Le scénario du redirect URI mismatch concerne spécifiquement le premier cas.
Une erreur sur une API key de service ne serait pas corrigée en ajoutant une redirect URI.
Il faut toujours diagnostiquer le mécanisme d’authentification réellement utilisé.
Diagnostiquer le problème à partir des symptômes
Voici une grille de raisonnement utile.
Symptôme
401 Unauthorized
Cela peut indiquer de nombreuses causes.
Il faut davantage d’informations.
Symptôme
redirect URI mismatch
Cette erreur pointe beaucoup plus précisément vers :
OAuth
+
redirect URI registration
La correction doit donc cibler cette configuration.
La correction ciblée
Dans le scénario du module, la correction est :
- enregistrer la redirect URI du host production auprès du provider OAuth ;
- vérifier si staging et production doivent utiliser des OAuth app registrations différentes ;
- ajouter cette étape à la deployment checklist.
Il n’est pas nécessaire de réécrire le flux d’authentification puisqu’il fonctionnait déjà en staging.
C’est un exemple important du principe :
Corriger la couche qui contient réellement le bug.
Éviter les corrections trop larges
Imaginons une équipe qui rencontre le redirect URI mismatch.
Elle pourrait être tentée de :
- réécrire le client OAuth ;
- changer le MCP server ;
- remplacer OAuth par une API key ;
- modifier tout le système d’identité.
Mais le diagnostic montre une cause beaucoup plus précise.
OAuth fonctionne
+
URI production absente
La meilleure correction est donc ciblée.
Ce type de raisonnement est particulièrement utile dans les questions de scénario.
Enterprise : vérifier les politiques par environnement
Le document rappelle qu’en environnement réglementé, les règles ne se limitent pas aux mécanismes techniques.
Une organisation peut imposer une politique telle que :
Staging OAuth app
≠
Production OAuth app
Avant de réutiliser la même registration, il faut donc vérifier la politique applicable.
Le principe général devient :
Ne pas déduire la configuration de production de celle du staging.
Chaque environnement doit être validé selon ses propres exigences.
Enregistrement, configuration et code : trois couches distinctes
Le scénario OAuth permet de distinguer trois couches.
Code
OAuth client logic
callback handling
token handling
Configuration applicative
production host
callback path
environment values
Configuration provider
registered redirect URIs
OAuth app registration
Le code peut être identique dans les deux environnements.
Mais la configuration du provider doit connaître le nouvel host.
Une méthode de vérification avant production
À partir du cas présenté dans le module, on peut appliquer cette séquence.
1. Identifier le host du nouvel environnement
Exemple :
production.mycompany.com
2. Identifier la redirect URI exacte utilisée par l’application
Elle doit correspondre au host production.
3. Vérifier l’enregistrement auprès du provider OAuth
L’URI doit figurer dans la configuration autorisée.
4. Vérifier la politique de séparation des environnements
Une OAuth app différente est-elle requise pour production ?
5. Tester l’authentification dans le nouvel environnement
Ne pas considérer les tests staging comme suffisants pour valider la configuration production.
Ce qu’il faut retenir pour la certification
OAuth fonctionne en staging mais échoue en production avec redirect URI mismatch
Pensez immédiatement :
production redirect URI non enregistrée ou incorrecte.
Pourquoi le code peut-il être correct malgré l’échec ?
Parce que les redirect URIs sont une configuration du provider OAuth liée au host de l’environnement.
Le host staging autorise-t-il automatiquement production ?
Non.
Les redirect URIs sont enregistrées explicitement.
Peut-on toujours utiliser la même OAuth app pour staging et production ?
Le fichier ne permet pas de l’affirmer.
Il indique que certains clients enterprise, notamment réglementés, peuvent exiger des registrations séparées.
Il faut donc vérifier la politique applicable.
Quand faut-il traiter cette configuration ?
Avant le déploiement.
Elle doit faire partie de la deployment checklist.
Une erreur redirect URI mismatch justifie-t-elle de changer complètement de mécanisme d’authentification ?
Non.
Le diagnostic pointe vers la configuration OAuth du host.
La correction doit être ciblée.
Piège d’examen
Scénario :
Une intégration MCP utilise OAuth et fonctionne parfaitement sur
staging.mycompany.com. Après déploiement surproduction.mycompany.com, chaque connexion échoue avecredirect URI mismatch. Quelle est la meilleure action ?
La logique est :
OAuth flow déjà validé
↓
nouveau host
↓
redirect URI différente
↓
vérifier/enregistrer l'URI production
La bonne correction est donc d’ajouter la redirect URI de production dans la configuration OAuth appropriée et de vérifier si une registration distincte est requise pour cet environnement.
Réécrire le flux OAuth serait une correction trop large par rapport au problème observé.
Conclusion
Le passage du staging à la production ne consiste pas uniquement à déployer le même code sur une autre infrastructure.
Avec OAuth, le changement d’environnement peut aussi modifier l’identité du host utilisé dans le flux d’authentification.
Le modèle à retenir est :
Staging host
↓
redirect URI staging
↓
OAuth provider registration
Production host
↓
redirect URI production
↓
OAuth provider registration
Chaque nouvel environnement doit donc être explicitement vérifié.
Et dans certains contextes enterprise :
Staging OAuth app
↓
staging
Production OAuth app
↓
production
peut être exigé par la politique de sécurité.
Le principe essentiel est simple :
Une authentification validée en staging ne garantit pas que la configuration OAuth de production existe.
Les redirect URIs et les OAuth app registrations doivent faire partie du processus de déploiement, au même titre que le code, les secrets et les autres paramètres d’infrastructure.
Dans la suite de la série
Claude Code en environnement réglementé : audit, configuration centralisée et data residency
Nous verrons pourquoi une intégration destinée à la finance, à la santé ou à un autre contexte réglementé doit répondre à des questions supplémentaires sur l’identité, l’audit des tool calls, le verrouillage administratif de la configuration et la localisation du traitement des données.
