Erreur Supabase : "Unsupported provider: provider is not enabled"

Vous ajoutez un bouton "Se connecter avec Google" à votre app et vous appuyez dessus. Au lieu du sélecteur de compte de Google, votre navigateur affiche ceci :

{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

La barre d'adresse montre votre projet Supabase, quelque chose comme https://abcdefghij.supabase.co/auth/v1/authorize?provider=google&redirect_to=…. Vous avez construit l'app avec Lovable, Bolt, v0, Cursor, Claude Code ou Replit, le bouton est venu avec le code, et rien dans ce code ne semble faux.

"Unsupported provider: provider is not enabled" signifie que Supabase Auth, la partie de Supabase qui connecte les gens, a Google désactivé dans le projet auquel votre app parle. La correction tient en un interrupteur et deux valeurs que Google vous donne. Ensuite, Google vérifie une liste à lui, et c'est de cette liste que vient l'erreur suivante, redirect_uri_mismatch.

Le piège est dans cette deuxième liste. L'adresse qui semble y avoir sa place est celle de votre propre app, et Google ne s'en sert jamais, parce que Google n'envoie personne vers votre app.

Que signifie "Unsupported provider: provider is not enabled" ?

Cela signifie que Supabase a refusé de lancer une connexion avec Google, parce que Google est désactivé dans le projet qui a reçu la demande.

Se connecter avec Google, c'est un aller-retour par deux accueils. Votre app envoie la personne à l'accueil de Supabase. Supabase l'envoie à l'accueil de Google pour prouver qui elle est, Google la renvoie à Supabase, et Supabase la renvoie chez elle, dans votre app, connectée. Chaque accueil n'envoie les gens que là où ses propres réglages l'autorisent. Ce message, c'est l'accueil de Supabase qui dit que son guichet Google est fermé.

Dans le code source de Supabase Auth, une demande à /auth/v1/authorize cherche d'abord le fournisseur, et tout problème avec lui revient en 400, avec le code validation_failed et Unsupported provider: devant la raison. provider is not enabled est la première chose que cette recherche vérifie.

Google n'a donc jamais vu la demande, et rien dans la console de Google ne l'expliquera. Votre app ne voit pas l'erreur non plus : la bibliothèque JavaScript de Supabase envoie tout le navigateur à cette adresse, la page qui échoue appartient donc à Supabase, et la console de votre app reste vide.

Le même message apparaît pour GitHub, Apple ou tout autre fournisseur désactivé, et l'interrupteur est au même endroit. Les apps sur le backend intégré de Lovable sont configurées autrement : la documentation sur l'authentification de Lovable présente Google comme "managed by Lovable with no setup, or your own Google Cloud OAuth credentials." Cet article s'adresse aux apps sur votre propre projet Supabase, quel que soit l'outil qui les a construites.

Est-ce le bon projet Supabase ?

Vérifiez-le avant de changer quoi que ce soit, car la page d'erreur nomme le projet qui a répondu.

L'adresse de la page d'erreur commence par la référence de votre projet, la suite de lettres avant .supabase.co. Ouvrez votre tableau de bord Supabase et regardez sa propre barre d'adresse : la même référence suit /project/. Si les deux diffèrent, votre app parle à un autre projet, par exemple un projet qu'un builder a créé pour vous ou une copie faite pour vos tests. C'est dans ce projet-là que Google doit être activé.

Comment corriger "Unsupported provider: provider is not enabled"

Créez un client OAuth chez Google, puis activez Google dans Supabase avec les deux valeurs qu'il vous donne. Le guide de connexion avec Google de Supabase contient les étapes ; les voici dans l'ordre où les deux consoles les demandent. Les libellés sont ceux des deux interfaces en anglais.

Dans Supabase, copiez d'abord l'URL de callback. Allez dans Authentication, puis Sign In / Providers, et ouvrez Google. Le panneau affiche une Callback URL avec un bouton pour la copier. Elle ressemble à https://<project-ref>.supabase.co/auth/v1/callback.

Dans Google Cloud, créez le client. Sur la page Clients de Google Auth Platform, créez un ID client OAuth de type Web application.

• Dans Authorized JavaScript origins, ajoutez l'adresse de votre app, par exemple https://yourapp.com.
• Dans Authorized redirect URIs, collez l'URL de callback copiée dans Supabase.
• Appuyez sur Create, et copiez tout de suite le Client ID et le Client Secret. La page d'aide de Google sur les clients OAuth prévient : "you will only be able to view and download the full client secret once, at the time of its creation."

De retour dans Supabase, activez-le. Activez Enable Sign in with Google, collez le Client ID dans Client IDs et le secret dans Client Secret (for OAuth), puis enregistrez. Le tableau de bord n'enregistre pas Google activé sans Client ID, mais il enregistre avec le champ du secret vide. La description de ce champ dit que le secret sert à "the OAuth flow on the web", et un bouton dans une app web, c'est exactement ce flux.

Appuyez ensuite à nouveau sur votre bouton. Si le message commence toujours par "Unsupported provider", sa fin dit ce qui reste à faire :

Pourquoi Google répond ensuite redirect_uri_mismatch

Parce que votre URL de callback n'est pas dans la liste du client, écrite exactement comme Supabase l'envoie.

C'est le deuxième accueil. Quand Supabase lance la connexion, il confie la personne à Google avec une note qui dit où la renvoyer : l'URL de callback de votre projet. Google compare cette note aux Authorized redirect URIs du client que vous avez créé. Sa documentation OAuth décrit l'échec en une ligne : "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID."

La correspondance est exacte. La même page dit : "the http or https scheme, case, and trailing slash ('/') must all match." Une entrée qui se termine par /auth/v1/callback/, avec une barre oblique à la fin, ne correspond donc pas à l'adresse que Supabase envoie.

L'adresse de votre propre app ne sert à rien dans cette liste. Google renvoie les gens vers Supabase, la seule adresse qu'il vérifie est donc le callback de Supabase. L'adresse de votre app va dans la liste de l'autre accueil, Redirect URLs chez Supabase, qui décide où Supabase envoie les gens tout à la fin. Quand cette liste est fausse, les gens reviennent connectés sur localhost:3000, et cela a son propre article.

Après avoir enregistré, laissez un peu de temps à Google. Sa page d'aide sur les clients OAuth dit : "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Où va le Client Secret

Dans le tableau de bord Supabase, et nulle part ailleurs. Le code de votre app n'en a jamais besoin.

Le Client ID est public : il circule dans l'adresse de la page de connexion de Google, où n'importe qui peut le lire. Le Client Secret est ce qui prouve à Google qu'une demande vient de votre côté, et dans ce montage seul Supabase le détient. Quand votre app appelle signInWithOAuth, la bibliothèque envoie le navigateur à Supabase, et c'est Supabase Auth qui parle à Google avec le secret.

Si votre builder a mis le secret dans le code de votre app, ou dans une variable dont le nom commence par VITE_ ou NEXT_PUBLIC_, il est donc dans le navigateur de chaque visiteur. Ces variables sont publiques par conception. La page d'aide de Google le dit sans détour : "Never add client secrets directly in your code or check them into version control systems such as Git or Subversion." Remplacez-le sur la page du client dans la console de Google : appuyez sur Add Secret, collez le nouveau secret dans Supabase, puis Disable sur l'ancien et supprimez-le. Retirez aussi l'ancienne valeur de votre code.

Pas besoin d'ouvrir le builder pour vérifier ce que votre app en ligne remet aux visiteurs. Notre scan gratuit lit votre app en ligne comme le fait le navigateur d'un visiteur et signale les clés secrètes qu'il reconnaît, ainsi que les tables qui répondent à tout le monde et les en-têtes manquants. Il prend environ 20 secondes et ne demande pas de compte : scannez votre app.

Veiller sur l'app où les gens se connectent désormais

Dès que des gens se connectent avec Google, leurs comptes vivent dans votre projet Supabase, et l'app où ils se connectent change à chaque déploiement.

Reeve Monitor continue de vérifier votre app en ligne :

• si elle répond, toutes les 60 secondes
• les neuf vérifications toutes les heures, sur jusqu'à trois apps, y compris les clés secrètes dans le code que votre app envoie aux visiteurs
• un message quand un résultat change, pour qu'une clé partie avec un déploiement ultérieur vous parvienne sans que vous alliez voir
• un rapport mensuel, en langage clair, de ce qu'il a vu

Reeve Care garde une copie de votre base de données Supabase, comptes compris :

• une copie chiffrée selon un calendrier, sur le stockage propre de Reeve dans l'UE, en dehors de votre compte Supabase
• le schéma auth, où Supabase garde chaque utilisateur et l'identité Google avec laquelle il s'est connecté, pour qu'ils reviennent avec tout le reste
• chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
• vos fichiers envoyés aussi, dès que vous connectez un accès Storage
• une restauration en un clic, avec une copie de sécurité de l'état actuel prise d'abord
• tout ce que fait Monitor

Que faire maintenant

Si les gens passent Google puis arrivent sur la mauvaise page, l'article sur les redirections prend le relais. La checklist de sécurité en 10 minutes couvre ce qu'il reste à regarder avant le lancement.