"Invalid login credentials" dans Supabase : les trois causes

Quelqu'un vous écrit qu'il n'arrive pas à se connecter à votre app, et il est sûr que le mot de passe est bon. Vous essayez son adresse vous-même et obtenez la même ligne rouge sous le formulaire :

Invalid login credentials

Supabase répond "Invalid login credentials" à un mauvais mot de passe. Il répond exactement les mêmes mots à deux autres personnes : quelqu'un dont l'e-mail n'a pas de compte dans votre app, et quelqu'un qui s'est inscrit avec Google et n'a jamais eu de mot de passe. Votre app Lovable, Bolt, v0, Cursor, Claude Code ou Replit fonctionne comme elle a été construite. Elle donne une seule réponse à trois situations différentes.

Voici ce que la correction évidente fait de travers : le message vague est délibéré, et le rendre plus utile ouvre une faille. Ce qui aide, c'est de savoir lequel des trois cas vous avez devant vous, ce que votre propre tableau de bord peut vous dire, pendant que le formulaire continue d'en dire aussi peu qu'aujourd'hui.

Que signifie "Invalid login credentials" dans Supabase ?

Cela signifie que Supabase Auth, la partie de Supabase qui connecte les gens, a refusé un e-mail et un mot de passe et garde la raison pour lui.

Le message est écrit dans le code même du serveur Auth. Dans la fonction qui traite une connexion par mot de passe, la même erreur est renvoyée à trois endroits : quand aucun utilisateur n'a cet e-mail, quand l'utilisateur n'a pas de mot de passe enregistré, et quand le mot de passe ne correspond pas. À chaque fois, la réponse est un HTTP 400 avec le code invalid_credentials, que la référence des codes d'erreur de Supabase décrit comme "Login credentials or grant type not recognized."

Dans votre app, elle arrive sous la forme d'une AuthApiError venant de signInWithPassword, avec error.code égal à invalid_credentials. La même référence demande d'identifier les erreurs toujours par error.code et error.name, et cela compte plus loin, quand vous déciderez de ce que dit votre formulaire. Si vos utilisateurs étaient connectés puis ont été éjectés, c'est une autre erreur, avec sa propre page.

Imaginez votre formulaire de connexion comme le digicode à côté de la porte d'un immeuble. Un visiteur tape un code et un voyant répond. Le vert ouvre la porte. Le rouge s'allume pour un mauvais code, pour un code qui n'a jamais été donné à personne, et pour un résident qui est toujours entré par la porte latérale avec un badge et n'a jamais eu de code.

Les trois personnes derrière le message

Chacune demande une correction différente, il vaut donc la peine de savoir laquelle vous avez devant vous.

Le mauvais mot de passe. Le compte existe, il a un mot de passe, et ce qui a été tapé ne correspond pas. Cela inclut un mot de passe changé sur un autre appareil puis oublié, et un gestionnaire de mots de passe qui remplit un ancien.

L'adresse sans compte. Personne dans votre projet ne s'est inscrit avec cet e-mail. Ce peut être une deuxième adresse (celle du travail, quand la personne s'est inscrite avec sa personnelle) ou une faute de frappe à l'inscription, désormais enregistrée comme son e-mail.

Le compte sans mot de passe. La personne s'est inscrite avec Google, GitHub ou un autre bouton de connexion, et Supabase n'a jamais enregistré de mot de passe pour elle. Quand elle revient et en tape un, il n'y a rien à comparer. Le serveur Auth vérifie qu'un mot de passe est enregistré avant de regarder celui qui est tapé, et un compte sans mot de passe reçoit le même 400.

Les personnes inscrites avec un magic link, le lien de connexion envoyé par e-mail, sont une variante du premier cas. Le code des magic links de Supabase crée leur compte avec un mot de passe aléatoire que personne ne voit jamais, donc tout mot de passe qu'elles tapent est faux.

Comment savoir de quel cas il s'agit ?

Demandez à votre propre base de données. Chaque compte de votre projet est une ligne dans une table appelée auth.users, et cette ligne dit comment la personne se connecte.

Le guide des utilisateurs de Supabase décrit le champ qui compte : selon Supabase, app_metadata.providers est la liste des fournisseurs avec lesquels l'utilisateur peut se connecter. Un utilisateur peut avoir plusieurs identités, donc une même personne peut avoir à la fois un mot de passe et Google. La présence d'un mot de passe figure dans la colonne que le serveur vérifie lui-même.

Ouvrez le SQL Editor de votre tableau de bord Supabase et lancez ceci avec l'adresse que la personne vous a donnée :

select email,
       raw_app_meta_data->'providers' as signs_in_with,
       coalesce(encrypted_password, '') <> '' as has_password,
       email_confirmed_at
from auth.users
where lower(email) = lower('person@example.com');

La requête lit une ligne et ne montre jamais de mot de passe, seulement s'il en existe un.

Si vous préférez cliquer plutôt que taper, Authentication → Users dans le tableau de bord affiche les mêmes comptes.

Le compte qui n'a jamais eu de mot de passe

Renvoyez la personne vers le bouton qu'elle a utilisé, ou laissez-la définir un mot de passe avec votre lien de réinitialisation.

Au digicode, c'est le résident qui a toujours pris la porte latérale. Aucun code n'est enregistré pour lui, donc chaque code qu'il essaie est refusé.

La première réparation se fait sur votre page de connexion. Si l'inscription propose "Continuer avec Google", la page de connexion a besoin du même bouton, pour que quelqu'un qui s'est inscrit avec le voie en revenant.

Si la personne veut aussi un mot de passe, votre lien "Mot de passe oublié ?" le permet déjà. Le code de réinitialisation du mot de passe de Supabase envoie l'e-mail de récupération à tout compte qu'il trouve, sans vérifier comment le compte a été créé. Un utilisateur Google qui suit le lien et définit un nouveau mot de passe peut ensuite se connecter des deux façons. Cela suppose que votre app a la page qui définit le nouveau mot de passe, celle qui appelle supabase.auth.updateUser({ password }). Si le lien mène à une page qui n'en demande jamais, la personne est connectée une fois et n'a toujours pas de mot de passe.

"Email not confirmed" veut dire que le mot de passe était bon

C'est un autre message avec un autre code, et il n'atteint que quelqu'un qui a déjà passé le contrôle du mot de passe.

Dans la même fonction du serveur Auth, la vérification de l'e-mail confirmé vient après celle du mot de passe. Email not confirmed, code email_not_confirmed, ne revient donc qu'à quelqu'un qui a tapé un e-mail existant et son bon mot de passe. La référence des erreurs de Supabase le formule ainsi : "Signing in is not allowed for this user as the email address is not confirmed." Au digicode, c'est un autre voyant : le code était bon, et la porte reste fermée tant que les papiers d'emménagement ne sont pas terminés.

Vous le voyez quand Confirm email est activé pour le fournisseur Email de votre projet. Selon le guide de configuration de Supabase, les utilisateurs doivent alors confirmer leur adresse e-mail avant de se connecter pour la première fois. La correction, c'est l'e-mail sur lequel la personne n'a pas encore cliqué : dites-lui de vérifier sa boîte de réception et ses spams, et proposez de le renvoyer avec supabase.auth.resend({ type: 'signup', email }). Si ces e-mails n'arrivent pas du tout, la limite d'envoi d'e-mails est la première chose à écarter. S'ils arrivent et que le lien répond "Email link is invalid or has expired", quelque chose l'a sans doute ouvert avant la personne.

Comme ce message n'apparaît qu'après un bon mot de passe, dire à la personne de vérifier sa boîte ne donne à un inconnu rien qu'il n'avait déjà.

Pourquoi le message reste vague

Parce que la version utile dirait à des inconnus qui sont vos utilisateurs.

Imaginez que le digicode réponde "personne n'habite au 4B". N'importe quel passant pourrait parcourir la liste des appartements et savoir lesquels sont occupés.

Votre formulaire fonctionne de la même façon. S'il disait "Aucun compte avec cet e-mail", quiconque détient une liste d'adresses pourrait les taper une par une et savoir lesquelles appartiennent à vos utilisateurs. Une fuite de données sur un autre site laisse une liste de ce genre derrière elle, parfois avec les mots de passe que les gens y utilisaient. Qui sait quelles adresses sont vos utilisateurs sait de qui il vaut la peine d'essayer les anciens mots de passe sur votre app, et qui ouvrira sans doute un e-mail qui semble venir de vous.

Supabase applique la même règle partout où l'on saisit une adresse. Son code d'inscription, quand on lui demande de créer un compte pour un e-mail déjà enregistré et confirmé, peut renvoyer un utilisateur inventé avec un identifiant aléatoire, via une fonction dont le commentaire dit qu'elle existe pour éviter de laisser fuiter si un utilisateur est enregistré ou non. La réinitialisation du mot de passe répond à une adresse inconnue par le même succès vide qu'à une adresse connue.

Côté inscription, il y a un interrupteur que vous contrôlez. Cet utilisateur inventé est ce qui revient quand la confirmation est exigée à la fois pour les inscriptions par e-mail et par téléphone. Si l'une des deux est désactivée (celle du téléphone compte même si votre app n'utilise jamais la connexion par téléphone), une adresse enregistrée reçoit User already registered, code user_already_exists, et votre formulaire d'inscription devient lui-même un vérificateur de listes.

Le message utile doit aussi venir de quelque part. Supabase ne dit pas à votre app si un e-mail a un compte, donc pour afficher "Aucun compte avec cet e-mail", votre app doit le découvrir elle-même. Cela veut dire une recherche qui fonctionne pour un visiteur non connecté : une lecture de votre table profiles qui ne réussit que si n'importe qui peut lire les e-mails qu'elle contient, ou une fonction de base de données qui cherche dans auth.users pour quiconque demande. Dans les deux cas, la liste de vos utilisateurs devient lisible de l'extérieur.

La première se voit de l'extérieur, et c'est ainsi que notre scan gratuit la cherche. Il demande à chaque table que votre app nomme combien de lignes un visiteur sans connexion pourrait obtenir, ne lit que le nombre, et prend environ 20 secondes, sans compte : scannez votre app.

Ce qu'il faut mettre sur votre page de connexion

Gardez le message vague et mettez toutes les façons de revenir sur la même page.

• Un seul message pour les trois cas, en mots simples, avec les autres chemins juste à côté : "L'e-mail et le mot de passe ne correspondent pas. Si vous vous êtes inscrit avec Google, utilisez le bouton ci-dessous." Il aide l'utilisateur Google et n'apprend à un inconnu rien que votre page d'inscription ne dise déjà.
• Toutes les méthodes de votre page d'inscription. Le bouton Google, le magic link et le champ mot de passe, tous aussi sur la page de connexion.
• Un lien "Mot de passe oublié ?" vers une page qui en définit un. Supabase y répond de la même façon à chaque adresse, il peut donc rester visible, et c'est ainsi qu'une personne sans mot de passe en obtient un.
• Des décisions selon error.code. Affichez votre message vague pour invalid_credentials, et "vérifiez votre boîte de réception" avec un bouton de renvoi pour email_not_confirmed. La référence des erreurs de Supabase demande d'identifier les erreurs par leur code plutôt que par le texte du message, et prévient que les codes de statut HTTP peuvent changer sans prévenir.

En code, ce sont deux branches :

const { error } = await supabase.auth.signInWithPassword({ email, password })
if (error?.code === 'email_not_confirmed') showCheckYourInbox(email)
else if (error) showSignInHelp()

Si un builder écrit votre page de connexion, vous pouvez lui coller ces quatre points comme consigne, y compris celui sur ce que la page doit garder pour elle.

Garder votre page de connexion telle que vous l'avez laissée

Deux choses peuvent encore mal tourner après aujourd'hui : un prompt ultérieur réécrit la page pour la rendre "plus utile", et un changement ailleurs perd les comptes auxquels la page donne accès.

Reeve Monitor continue de vérifier depuis l'extérieur :

• les neuf vérifications toutes les heures, sur jusqu'à trois apps, dont le nombre de lignes qu'un visiteur sans connexion peut compter dans les tables que votre app nomme
• un e-mail le jour où un nouveau scan note votre app moins bien que le précédent
• si l'app répond, toutes les 60 secondes
• 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ù vivent les comptes de vos utilisateurs, 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 le problème commence une étape plus tôt et que les nouveaux comptes ne sont même pas créés, Database error saving new user couvre ce bout-là du formulaire. La checklist de sécurité en 10 minutes couvre ce qui reste souvent ouvert dans une app qui vient d'être lancée.