Réparer la connexion OAuth cassée dans des applications générées par IA (production)

Ce qui casse réellement quand OAuth échoue en production

Les échecs OAuth paraissent déroutants parce que votre code semble souvent correct. Le fournisseur fait ce que vous lui demandez, mais un petit décalage entre local et production fait échouer la poignée de main.

« Ça marche en local mais échoue en production » ressemble généralement à ceci : vous cliquez sur Google ou GitHub, revenez dans votre app, et tombez sur une page blanche, une 401/403, ou une boucle de redirection infinie qui renvoie au bouton de connexion. Parfois le fournisseur affiche une erreur claire (souvent sur l'URL de redirection). D'autres fois, ça semble réussi, mais l'app oublie immédiatement qui vous êtes après le callback.

OAuth est pointilleux parce qu'il dépend d'URLs exactes et des règles du navigateur. Le fournisseur compare votre redirect URI à celle enregistrée. Votre app doit lire le callback, valider l'état de connexion, et définir un cookie de session que le navigateur renverra ensuite. De petites différences comme http vs https, www vs non-www, ou un flag de cookie peuvent faire la différence entre « connecté » et « qui êtes-vous ? »

Symptômes courants en production :

• Le fournisseur se plaint d'un mismatch d'URI de redirection
• Le callback atteint votre app puis redirige en boucle
• La connexion marche une fois, puis les utilisateurs sont déconnectés au rafraîchissement
• Seuls certains utilisateurs échouent (souvent Safari, iOS, ou navigation privée)
• Les erreurs n'apparaissent que derrière un proxy ou sur le vrai domaine

Les apps générées par IA raccordent souvent l'auth de manière fragile : URLs de callback codées en dur, vérifications d'état manquantes, et paramètres de cookie qui passent en local mais échouent sous HTTPS réel, vrais domaines et les comportements de confidentialité des navigateurs modernes.

Cartographiez votre flux de connexion avant de toucher quoi que ce soit

La façon la plus rapide de perdre du temps est de commencer à changer des paramètres au hasard sans carte claire. OAuth est une chaîne. Une mauvaise hypothèse sur quelle URL est utilisée, où la session vit, ou où HTTPS est terminé peut casser tout le flux.

Notez le flux de production exact (pas ce que vous supposez depuis le local). Beaucoup d'apps générées par IA changent les URLs de base selon des variables d'environnement, et certaines ont plusieurs routes de callback (Google vs GitHub, web vs mobile).

Capturez ces détails pour comparer local vs staging vs production :

• Origine du frontend (ce que le navigateur charge) et origine de l'API (où vont les requêtes)
• L'URL de callback que votre app reçoit après la redirection du fournisseur
• L'URI de redirection enregistrée chez le fournisseur OAuth (chaîne exacte)
• Où la session est stockée (cookie, token dans localStorage, ou session serveur)
• Votre configuration edge (reverse proxy/CDN) et l'endroit où HTTPS devient HTTP

Vérification de réalité : si votre proxy termine HTTPS, votre serveur d'app peut voir des requêtes en http à moins que les en-têtes transférés soient correctement configurés. Cela peut changer les callback URLs générées et les flags de sécurité des cookies.

Exemple : en local tout marche parce que tout est http://localhost sur un seul domaine. En production, le frontend est sur app.example.com, l'API sur api.example.com, et le callback arrive sur le mauvais hôte. Le fournisseur redirige avec succès, mais votre cookie de session est écrit pour le domaine API et n'atteint jamais le frontend. Résultat : une boucle « déconnecté ».

Mismatch d'URI de redirection : la façon la plus rapide de casser le login social

Pour un gain rapide, commencez par l'URI de redirection. Un caractère de différence et le fournisseur bloquera le callback.

La plupart des fournisseurs exigent une correspondance exacte, y compris :

• Schéma (http vs https)
• Domaine (www vs non-www, sous-domaines)
• Chemin (y compris la barre oblique finale)
• Paramètres de requête (présents, manquants, ou ordre différent)
• Port (commun en dev local)

Les problèmes en production viennent souvent du mélange d'environnements. Vous avez testé sur un domaine de staging, puis lancé avec un domaine personnalisé, mais le fournisseur n'autorise que le callback de staging. Autre cas fréquent : un outil génère plusieurs URLs de déploiement (builds de preview, URLs temporaires), et l'app construit par erreur le callback avec la mauvaise.

Les proxies aggravent souvent la situation. Si votre app pense qu'elle tourne en http, elle peut générer une redirect URI en http alors que le site réel est en https. En production, cela se traduit par une erreur du fournisseur comme “redirect_uri mismatch” ou une page blanche après la connexion.

Exemple simple : en local vous utilisez http://localhost:3000/auth/callback, mais en production cela devrait être https://app.yourdomain.com/auth/callback (sans slash final). Si votre code génère https://app.yourdomain.com/auth/callback/, certains fournisseurs traitent ça comme une URL différente et le rejettent.

Mauvaise gestion du callback et boucles de redirection

À la fin d'OAuth, le fournisseur renvoie l'utilisateur à votre app avec une preuve qu'il s'est connecté. Si votre route de callback est traitée comme une page normale, de petites erreurs peuvent tourner en boucles ou en « marche en local, échoue en prod ».

Ce que la route de callback devrait faire

Un endpoint de callback doit être court et ennuyeux. S'il tente de rendre une interface, d'appeler des données utilisateur d'abord, ou de passer par votre router normal avec des guards d'auth, il est facile de créer une boucle.

Un handler de callback sain fait ceci :

• Lire la réponse du fournisseur (code, state, et tout champ error).
• Échanger le code contre des tokens (côté serveur) et valider la réponse.
• Créer ou reprendre une session (définir les cookies appropriés) et stocker l'identité utilisateur.
• Rediriger vers une page sûre « vous êtes connecté ».

Un bug courant dans le code généré par IA est de charger l'app complète sur le callback. Le guard d'auth de l'app voit « pas encore connecté » et redirige immédiatement vers le fournisseur, créant une boucle.

Gérer les erreurs du fournisseur sans planter

Les fournisseurs retournent régulièrement des erreurs comme access_denied (utilisateur a annulé) ou invalid_grant (code expiré ou déjà utilisé). Si votre code suppose qu'un code est toujours présent, vous obtenez un 500, puis le frontend réessaie, et la boucle continue.

Gardez la gestion d'erreur simple :

• Si error existe, affichez un message lisible et proposez un bouton « Réessayer ».
• Si l'échange de token échoue, loggez une erreur sanitizée et arrêtez le flux.
• Ne réutilisez pas le même auth code lors d'un retry. Lancez une nouvelle tentative de login.

Surveillez aussi les redirections post-login. Beaucoup d'apps acceptent un paramètre returnTo et redirigent aveuglément vers lui. Cela peut créer des chemins cassés (retour dans /auth/callback) et un risque d'open-redirect. Autorisez seulement des chemins same-site, par défaut vers une page connue, et nettoyez tout ce qui paraît suspect.

Validation de l'état manquante et pourquoi ça échoue de façon intermittente

La valeur state est une balise de sécurité que votre app crée avant d'envoyer quelqu'un vers Google, GitHub, ou un autre fournisseur. Quand le fournisseur redirige, votre app doit vérifier que le state retourné correspond à celui émis. Cela bloque les attaques CSRF et confirme que le callback appartient à la même session navigateur.

Quand state manque, est stocké incorrectement, ou n'est pas validé, le comportement paraît aléatoire :

• Erreurs « Invalid state » ou « CSRF detected » que les utilisateurs ne reproduisent pas toujours
• La connexion marche une fois, puis échoue à la tentative suivante
• Les utilisateurs se connectent puis sont immédiatement déconnectés après le callback
• Rapports du type « ça marche sur mon laptop mais pas en production »

Pourquoi c'est intermittent en production : le state doit survivre entre la redirection initiale et le callback. Les apps le stockent généralement en session serveur (mémoire, Redis, base), ou dans un cookie de courte durée.

Si c'est en mémoire serveur, la production casse dès que vous avez plus d'une instance. La requête initiale peut toucher le serveur A, tandis que le callback touche le serveur B qui n'a jamais vu ce state.

Si c'est en cookie, les réglages de production peuvent le faire disparaître silencieusement : Secure manquant derrière HTTPS, mauvais domaine de cookie, ou SameSite qui le bloque lors de la redirection cross-site.

Vérifiez aussi PKCE. Pour beaucoup de fournisseurs, les clients publics (SPAs, mobile, et certains setups sans backend) doivent utiliser PKCE : l'app crée un code_verifier, le transforme en code_challenge, et le prouve ensuite lors de l'échange. Si PKCE manque ou est mismatched, les échecs n'apparaissent que sur certains appareils ou navigateurs.

Problèmes de cookie : SameSite, Secure, domain et path

Beaucoup d'échecs OAuth sont en réalité des échecs de cookie. Votre app définit un cookie de session (ou un cookie temporaire pour le flux OAuth), mais le navigateur ne le renvoie pas lors du callback. Le fournisseur est correct, pourtant votre app ne peut pas reconnecter l'utilisateur à la session.

SameSite : pourquoi les callbacks se comportent différemment

Les flux OAuth sautent entre sites (votre app -> fournisseur -> votre app).

Avec SameSite=Lax, les cookies sont envoyés sur les navigations top-level dans beaucoup de cas, mais des cas limites apparaissent avec des callbacks POST, des iframes, ou des vues web personnalisées. Si votre flux a réellement besoin des cookies lors d'un callback cross-site, vous aurez souvent besoin de SameSite=None.

Si vous mettez SameSite=None, vous devez aussi définir Secure, sinon les navigateurs modernes ignorent le cookie.

Secure, domain et path : petits réglages, grand impact

La production tourne en HTTPS et généralement sur de vrais domaines plutôt que localhost. Vérifiez :

• Secure est activé sur HTTPS, et non requis par erreur en HTTP local
• Le Domain du cookie correspond à ce que le navigateur voit (vérifiez app.example.com vs example.com)
• Le Path du cookie n'est pas trop restrictif (par ex. /api quand votre callback frappe /auth/callback)
• Les cookies ne sont pas écrasés lors de la redirection par des réglages différents
• Le callback n'est pas servi depuis un sous-domaine différent de celui où le cookie a été défini

Les erreurs CORS sont bruyantes. Les erreurs de cookie sont silencieuses. Un bon indicateur : si l'appel réseau réussit (200/302) mais que l'utilisateur reste déconnecté, c'est généralement un problème de cookie plutôt que de CORS.

Enfin, les navigateurs embarqués (webviews) et les nouvelles restrictions sur les cookies tiers peuvent casser le login social d'une manière que vous ne reproduirez pas sur Chrome desktop. Testez sur l'appareil et l'environnement réels de vos utilisateurs.

Erreurs de configuration propres à la production à vérifier

Souvent le bug n'est pas dans le code, mais dans la configuration production. Le local est indulgent ; la production est plus stricte.

Commencez par les variables d'environnement qui contrôlent OAuth. Une mauvaise valeur peut produire une belle page de connexion suivie d'un vague « quelque chose s'est mal passé » après la redirection.

Les mismatches de config les plus courants

• Client ID et client secret proviennent de la mauvaise app (identifiants dev utilisés en prod, ou l'inverse).
• Callback URL ou les redirect URLs autorisés ne correspondent pas exactement au schéma, domaine et chemin de production.
• L'API base URL pointe vers localhost ou staging, donc le callback échange un code contre le mauvais serveur.
• Les réglages de cookie et de session diffèrent en prod (Secure, domain, path), donc la session ne peut être lue pendant le callback.
• Un secret tourné a été mis à jour à un endroit mais pas à un autre (config d'hôte vs console du fournisseur).

Si vous avez hérité d'un projet généré par IA, vérifiez aussi les « quick fixes » où des secrets ont été collés dans le frontend ou loggés dans la console. Cela peut faire passer un test une fois, mais crée un vrai problème de sécurité et casse de nouveau à chaque changement de build.

Rare mais réel : le décalage horaire

Les échanges OAuth peuvent échouer si l'heure du serveur est fausse. C'est rare, mais si des tokens semblent expirés immédiatement, vérifiez la synchronisation horaire de l'hébergement et des images de conteneur.

Pas à pas : diagnostiquer une connexion OAuth cassée de bout en bout

Le chemin le plus rapide est de rendre l'échec reproductible et visible. Traitez-le comme un bug de checkout : un chemin, un navigateur, une preuve claire « voici la première étape qui casse ».

Utilisez un compte test chez le fournisseur et un profil navigateur neuf (sans extensions, sans gestionnaire de mots de passe). Si le bug « n'arrive que parfois », réduisez les variables.

Un flux simple qui trouve les causes racines rapidement :

1. Reproduisez une fois, puis arrêtez. Ne réessayez pas 10 fois et n'effacez pas la trace originale.
2. Capturez la chaîne complète de redirection et copiez l'URL exacte qui échoue (y compris la query string).
3. Comparez les URIs de redirection autorisées chez le fournisseur avec l'URL de callback déployée que vous avez capturée.
4. Inspectez les cookies juste avant le départ vers le fournisseur, et juste après votre retour. Confirmez Domain, Path, Secure, et SameSite.
5. Vérifiez que state et PKCE sont créés, stockés et validés. Confirmez que le state envoyé est le même que celui vérifié au retour.

Si les étapes 1–5 semblent correctes, concentrez-vous sur l'échange de token côté serveur. Votre backend doit recevoir le code, l'échanger contre des tokens, et gérer les erreurs sans boucler. Loggez la réponse d'erreur du fournisseur de façon sanitizée, et renvoyez une page d'échec claire au lieu de rebondir indéfiniment vers /login.

Les bases de code générées par IA contiennent souvent de la logique de retry « utile » ou des routes de callback dupliquées qui rendent le comportement en prod imprévisible.

Pièges courants qui aggravent les bugs OAuth

Sous pression, il est facile de patcher les symptômes et de rendre le vrai problème plus difficile à diagnostiquer.

Un mensonge courant est d'enregistrer une pile d'URIs de redirection « juste pour que ça marche ». Vous vous retrouvez avec des quasi-dupliqués entre staging, production et URLs de preview, et personne ne sait laquelle l'app utilise. Un déploiement ultérieur change de domaine et la connexion casse de nouveau.

Autre piège : désactiver la validation d'état pour arrêter les erreurs « state mismatch ». Cette erreur signale généralement un vrai problème (cookies, multi-onglets, routage multi-instance, callback cassé). Désactiver l'état supprime une protection importante et augmente le risque.

Le stockage des tokens est un autre point faible. Beaucoup d'apps générées par IA placent les access tokens dans localStorage parce que c'est facile. Si un XSS existe, les tokens sont faciles à voler. Préférez les sessions serveur ou les cookies httpOnly quand c'est possible.

Les patterns qui causent souvent des échecs en production incluent des domaines de cookie mal configurés, le mélange de routes SPA et API de sorte que le callback frappe le mauvais handler, masquer des boucles avec des redirections côté client supplémentaires, et copier du code fournisseur sans gérer les paramètres spécifiques du fournisseur.

Exemple : votre route de callback existe dans la SPA, mais le fournisseur envoie les utilisateurs vers un chemin API. En local cela fonctionne grâce aux rewrites dev ; en production la routage de la plateforme est plus strict.

Checklist rapide avant de déployer le correctif

Testez la connexion comme vos utilisateurs la vivront : un navigateur propre, un vrai domaine HTTPS, et les paramètres réels du fournisseur.

Checklist :

• Redirect URI correspond exactement : même schéma (https), hôte, chemin et barre finale que dans les réglages du fournisseur.
• Le callback se termine clairement (pas de boucle) : il crée la session et redirige une fois, ou affiche une page d'erreur claire.
• L'état est par tentative et validé : générez un nouveau state à chaque tentative, stockez-le en sécurité, et vérifiez-le au retour.
• Les cookies survivent au callback : confirmez la présence des cookies après la redirection. En HTTPS ils doivent être Secure, et SameSite doit correspondre à votre flux (certains flux nécessitent None + Secure). Vérifiez aussi domain et path.
• La config production est réelle, pas vide : client ID/secret, callback URL, base URL de l'app, et origines autorisées correspondent au domaine déployé.

Faites un passage en profil neuf (pas de cookies existants), puis sur mobile. Si cela ne marche que lorsque vous avez déjà été connecté une fois, vous avez probablement encore un problème de cookie ou de state.

Un exemple réaliste : local marche, production casse

Un fondateur déploie une app générée par IA qui connecte bien en local. Dès qu'il passe sur le vrai domaine, la connexion Google échoue avec une erreur claire : redirect_uri_mismatch.

Ils mettent à jour les paramètres du fournisseur. L'erreur disparaît, mais maintenant l'app rebondit entre le fournisseur et le site en boucle. Parfois elle atterrit sur la page d'accueil toujours déconnectée.

Deux petites différences en production suffisent souvent à causer cela :

D'abord, l'URI de redirection est presque correcte, mais pas exacte. Par exemple, l'app envoie https://app.example.com/auth/callback/ (slash final) alors que le fournisseur autorise https://app.example.com/auth/callback (sans slash).

Ensuite, le cookie de session qui stocke l'état de connexion n'est pas renvoyé sur le callback. En production, cela arrive souvent quand SameSite ne convient pas au flux, ou quand Secure est absent sur HTTPS.

Un chemin de résolution pratique :

• Faites correspondre exactement l'app et l'URI de redirection du fournisseur (schéma, hôte, chemin, slash final).
• Configurez correctement les cookies en production (Secure, SameSite adapté, domain et path corrects).
• Confirmez que l'app persiste et valide le state durant la redirection.

Pour confirmer la correction, testez en navigation privée, puis en fenêtre normale, puis après un redémarrage complet du navigateur. Essayez au moins deux navigateurs. Le résultat attendu : une redirection sortante, une redirection de retour, et vous restez connecté.

Étapes suivantes si votre auth générée par IA reste instable

Si les vérifications habituelles ne résolvent rien, arrêtez de changer les paramètres au hasard. La plupart des bugs « presque fonctionnels » viennent de logs manquants, d'un manque de clarté sur qui possède quelles URLs, ou de chemins de code emmêlés qui se comportent différemment sous de vrais domaines et HTTPS.

Notez les URLs de production exactes impliquées : votre base URL, l'URL callback du fournisseur, et toutes les pages de redirection intermédiaires. Verrouillez-les dans les réglages du fournisseur. De petites différences (www vs non-www, slash final, http vs https) peuvent créer des échecs qui paraissent intermittents parce que les utilisateurs arrivent par des points d'entrée différents.

Ajoutez du logging minimal autour du callback pour voir ce qui a échoué sans divulguer de secrets. Loggez horodatage, nom du fournisseur, statut HTTP et un code d'erreur interne sûr. N'imprimez pas de tokens, codes d'auth, cookies de session ou chaînes de requête complètes.

Si le code est généré par IA, l'instabilité vient souvent d'handlers d'auth dupliqués, d'approches de session mixtes (cookies plus localStorage), ou de redirections qui masquent de vraies erreurs. Un refactor ciblé est souvent plus rapide que des patchs :

• Une endpoint de callback par fournisseur
• Valider state (et nonce si applicable) en un seul endroit, à chaque fois
• Restreindre les redirections post-login à une petite allowlist
• Centraliser les réglages de cookie (Secure, SameSite, domain, path)
• Fournir une page d'erreur claire pour les connexions échouées

Si vous avez hérité d'un prototype en désordre et que la connexion prod continue de casser, FixMyMess (fixmymess.ai) est conçu pour cette situation. Nous diagnostiquons les bases de code générées par IA, réparons la logique d'auth, durcissons les cookies et les contrôles de sécurité, et préparons l'app pour des déploiements en production.