Pour tester les callbacks OAuth en local, il faut une URL HTTPS publique mappée à votre app. Les providers OAuth redirigent vers une URL de callback enregistrée — et la plupart exigent HTTPS, que localhost seul ne fournit pas sans configuration supplémentaire.
Pourquoi les redirect URIs bloquent localhost
Les providers OAuth valident le redirect_uri contre une liste blanche. Un tunnel localhost fournit un endpoint HTTPS réel sur votre machine, évitant les déploiements staging pour chaque changement auth.
Ce dont vous avez besoin
- Identifiants OAuth (client ID et secret) du provider.
- Une app locale avec routes login et callback.
- URL tunnel enregistrée comme redirect URI autorisé.
- Variables d'environnement pointant vers l'URL tunnel.
Étapes : test OAuth avec PortPreview
- Lancez votre app avec routes OAuth actives.
- Exécutez
npx portpreview 3000. - Ajoutez l'URL callback dans le dashboard du provider.
- Mettez à jour vos variables d'environnement.
- Testez le flux OAuth complet dans le navigateur.
- Vérifiez l'échange de tokens et la création de session.
Conseils par provider
Google OAuth : autorise http://localhost mais HTTPS valide le comportement proche production.
GitHub OAuth : correspondance exacte des redirect URIs requise.
Auth0 et IdP enterprise : souvent HTTPS obligatoire — les tunnels sont la solution standard.
Erreurs courantes
- Redirect URI non correspondant (slashes, casse).
- URL tunnel obsolète entre sessions.
- Paramètre
statenon validé (risque CSRF).
Sécurité et partage d'équipe
Ne exposez jamais les client secrets côté frontend. Consultez notre guide sécurité tunnel localhost et partage du serveur de dev local. Rejoignez la waitlist PortPreview.
Quand passer du local au staging
Le test OAuth local valide redirect URIs, échange de tokens et gestion d'erreurs. Passez en staging pour secrets managés, cookies domain-scoped et pipelines release complets. Pour les revues cross-device, combinez avec tests mobile via tunnel.