Erreur PostgreSQL : password authentication failed for user

SQLSTATE 28P01 (invalid_password) · Mis à jour 9 juillet 2026

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "app_user"

Vous avez atteint le serveur, pg_hba.conf a sélectionné une méthode d'authentification par mot de passe pour cette connexion, et la vérification du mot de passe a échoué. Le message client est délibérément vague ; le journal du serveur en dit généralement plus.

Ce que signifie cette erreur

Le client ne reçoit que « authentication failed » — c'est intentionnel, pour éviter de divulguer des informations aux attaquants. Le journal du serveur, en revanche, enregistre la raison sous-jacente au même horodatage : le rôle n'ayant aucun mot de passe assigné, le mot de passe ne correspondant pas, ou le format de mot de passe stocké n'étant pas utilisable avec la méthode d'authentification exigée par pg_hba.conf.

Ce dernier point mérite un mot : les mots de passe sont stockés hachés, en utilisant l'algorithme qu'avait password_encryption lorsque le mot de passe a été défini (scram-sha-256 sur les versions modernes, md5 historiquement). Changer password_encryption ou la méthode pg_hba ne convertit pas les mots de passe déjà stockés — les incohérences se manifestent par des échecs de connexion pour des mots de passe « assurément corrects ».

Causes fréquentes

• Mauvais mot de passe ou mauvais utilisateur — y compris « bon mot de passe, mauvais environnement » : des identifiants de staging contre la production, ou un mappage de port Docker pointant vers une instance différente de celle que vous croyez.
• Le rôle n'a pas de mot de passe défini (créé avec CREATE ROLE et jamais doté d'un). Tout mot de passe échoue ; seul le journal du serveur dit pourquoi.
• Incohérence SCRAM/md5 : mot de passe stocké en md5 alors que pg_hba exige scram-sha-256, ou une bibliothèque cliente très ancienne qui ne parle pas SCRAM.
• Caractères spéciaux dans un URI de connexion (@, :, /, # dans le mot de passe) non percent-encodés, si bien que le mot de passe analysé n'est pas celui que vous avez saisi.

Comment la diagnostiquer

• Lisez le journal du serveur à l'horodatage de l'échec — il nomme presque toujours la vraie cause.
• Vérifiez quelle règle pg_hba la connexion correspond : SELECT * FROM pg_hba_file_rules; montre les règles analysées dans l'ordre (la première correspondance l'emporte).
• Testez directement avec psql, en retirant l'application, l'analyse d'URI et le pooler de l'équation : psql "host=... user=app_user dbname=appdb" et saisissez le mot de passe de façon interactive.

Comment la corriger

• Réinitialisez le mot de passe — préférez le \password de psql à une instruction SQL brute, afin que le nouveau mot de passe ne finisse pas dans le journal du serveur ni dans l'historique du shell :

  \password app_user

• Alignez toute la pile sur SCRAM : définissez password_encryption = 'scram-sha-256', utilisez scram-sha-256 dans pg_hba.conf, et redéfinissez chaque mot de passe après le changement pour que les hachages stockés correspondent.
• Percent-encodez les mots de passe dans les URI, ou passez le mot de passe via PGPASSWORD/.pgpass/paramètres de connexion au lieu de l'URI.