OAuth « redirect_uri_mismatch » : corriger l’URL de callback sans affaiblir la sécurité

ParKelvin Carretero-Corrales

Réponse courte : l’erreur OAuth redirect_uri_mismatch signifie que l’URL de retour réellement envoyée au serveur d’autorisation ne correspond pas exactement à une URL autorisée pour ce client. La bonne correction consiste à comparer les deux valeurs caractère par caractère, puis à corriger la configuration de l’application, du fournisseur d’identité ou du reverse proxy. Il ne faut ni désactiver le contrôle ni ajouter un joker trop large.

Pourquoi OAuth exige une correspondance exacte

Après l’autorisation de l’utilisateur, le serveur OAuth renvoie le navigateur vers une URL de callback, aussi appelée URI de redirection. Cette adresse peut recevoir un code d’autorisation qui sera ensuite échangé contre des jetons. Si un attaquant pouvait choisir librement cette destination, il pourrait tenter de récupérer ce code.

La RFC 9700, qui formalise les bonnes pratiques de sécurité OAuth 2.0, recommande donc une comparaison exacte des URI de redirection enregistrées. Cette règle n’est pas un détail administratif : elle participe directement à l’identification du client et à la protection du flux.

Concrètement, ces deux adresses sont différentes pour un fournisseur qui applique une comparaison stricte :

  • https://app.exemple.fr/auth/callback
  • https://app.exemple.fr/auth/callback/

Le slash final suffit à provoquer l’erreur. Google précise également que le schéma http ou https, la casse et le slash final doivent correspondre.

Les différences à vérifier en premier

La comparaison doit porter sur la valeur de redirect_uri effectivement envoyée dans la requête d’autorisation, pas seulement sur ce que vous pensez avoir configuré. Les écarts les plus fréquents sont :

  • le schéma : http:// au lieu de https:// ;
  • l’hôte : domaine public, sous-domaine, www, localhost ou 127.0.0.1 ;
  • le port : port absent, explicite ou différent, par exemple :3000 ;
  • le chemin : /oauth/callback au lieu de /auth/callback ;
  • le slash final : présent d’un côté seulement ;
  • la casse : notamment dans le chemin ;
  • l’environnement : URL de développement envoyée avec le client de production, ou inversement.

Il faut aussi vérifier que le bon client_id est utilisé. Une URL peut être correctement déclarée pour un client OAuth et manquer dans la configuration d’un autre client du même projet.

Méthode de diagnostic sûre, étape par étape

1. Capturer la valeur réellement envoyée

Ouvrez les outils de développement du navigateur, onglet Réseau, puis relancez la connexion. Repérez la requête vers le point d’autorisation et copiez uniquement la valeur décodée du paramètre redirect_uri. Une trace applicative peut convenir, à condition de masquer les données sensibles.

Ne copiez pas dans un ticket public le code d’autorisation, les jetons, le secret client, la valeur state ni les cookies. Pour ce diagnostic, seule l’URL de redirection est nécessaire.

2. Comparer avec la liste du fournisseur

Dans la console du fournisseur d’identité, ouvrez le client OAuth concerné et comparez l’URL capturée avec les URI de redirection autorisées. Faites une comparaison littérale : schéma, nom d’hôte, port, chemin et slash final. Évitez de « normaliser mentalement » les deux adresses.

Exemple : si l’application envoie https://outil.exemple.fr/login/oauth/callback, cette valeur exacte doit être déclarée. Enregistrer uniquement https://outil.exemple.fr ne suffit pas.

3. Corriger la source de l’URL

Selon le framework, l’URL provient d’une variable d’environnement, d’une URL de base publique, d’une option de bibliothèque OAuth ou d’une valeur calculée à partir de la requête. Corrigez la source qui génère l’URL ; évitez de multiplier des entrées presque identiques pour masquer le problème.

Séparez clairement les callbacks de développement, de préproduction et de production. Chaque environnement doit utiliser son propre client OAuth lorsque le niveau d’isolation attendu le justifie, avec une liste d’URI limitée à ses véritables destinations.

4. Vérifier le reverse proxy

Un cas classique apparaît derrière un proxy, un ingress ou un répartiteur de charge : l’utilisateur visite une URL publique en HTTPS, mais l’application croit recevoir une requête HTTP sur un hôte interne. Elle construit alors une mauvaise URL de callback.

La correction consiste à définir l’URL publique canonique et à configurer l’application pour ne faire confiance qu’aux en-têtes transmis par des proxies connus. Accepter aveuglément n’importe quel en-tête Forwarded ou X-Forwarded-* peut créer d’autres vulnérabilités.

5. Contrôler l’échange du code

Dans le flux Authorization Code, si redirect_uri était présent dans la requête d’autorisation, la RFC 6749 impose de renvoyer une valeur identique lors de la requête au point de terminaison de jetons. Une première redirection correcte peut donc être suivie d’un échec à l’échange si les deux étapes ne partagent pas la même configuration.

Ce qu’il ne faut pas faire

  • Ne désactivez pas la validation de l’URI de redirection pour débloquer les tests.
  • N’ajoutez pas de joker large couvrant des sous-domaines ou chemins que d’autres utilisateurs peuvent contrôler.
  • N’utilisez pas un redirecteur ouvert comme callback intermédiaire.
  • Ne remplacez pas HTTPS par HTTP en production pour contourner un problème de proxy.
  • Ne supposez pas que PKCE ou state remplacent ce contrôle : ces mécanismes répondent à d’autres risques et doivent rester activés.

La seule exception courante à connaître concerne certaines applications natives utilisant une redirection vers l’interface de boucle locale : la RFC 8252 permet au port de varier, car le système peut attribuer dynamiquement un port disponible. Cette règle spécifique ne justifie pas un assouplissement général pour une application web.

Checklist avant de retester

  • la valeur envoyée dans redirect_uri a été capturée sans exposer de secret ;
  • elle correspond exactement à une URI autorisée du bon client_id ;
  • le schéma, l’hôte, le port, le chemin, la casse et le slash final ont été vérifiés ;
  • l’URL publique est correctement reconstruite derrière le reverse proxy ;
  • la même valeur est utilisée lors de l’échange du code ;
  • les callbacks de développement et de production sont séparés ;
  • state et PKCE restent activés lorsque le flux et le client les requièrent ;
  • les journaux masquent les codes, jetons et autres paramètres sensibles.

Questions fréquentes

Pourquoi l’URL semble-t-elle identique alors que l’erreur persiste ?

Le navigateur peut afficher une URL décodée alors que l’application envoie une valeur encodée, ou une différence peut se cacher dans le port, la casse, le slash final ou le client OAuth utilisé. Copiez les deux valeurs dans un outil de comparaison textuelle et vérifiez le client_id de la même requête.

Puis-je autoriser toutes les URL de mon domaine ?

Ce n’est pas une bonne valeur par défaut. Une règle large augmente le risque qu’un sous-domaine oublié, un hébergement temporaire ou un redirecteur ouvert devienne une destination exploitable. Préférez une courte liste d’URI complètes et possédées.

Faut-il modifier le fournisseur OAuth ou l’application ?

Corrigez l’élément faux. Si l’application doit réellement revenir sur une nouvelle route publique, enregistrez cette URI exacte chez le fournisseur. Si elle génère une adresse interne, un mauvais schéma ou une URL d’un autre environnement, corrigez sa configuration.

Conclusion

Une erreur redirect_uri_mismatch se résout rarement par une modification compliquée : il faut identifier la valeur réellement envoyée, retrouver l’écart exact et corriger sa source. Cette rigueur évite surtout de transformer un incident de configuration en faille de redirection.

Si le problème concerne l’authentification d’une application ou d’un mini-outil, les prestations Applications & outils numériques de FuretSplick donnent le cadre des développements et diagnostics qui peuvent être étudiés, avec un périmètre défini avant intervention.

Sources

Publications similaires