28000FATALTier 1 — Safe✅ HIGH confidence

invalid authorization specification

Category: Invalid Authorization SpecificationVersions: All Postgres versions

What this means

Postgres rejected the connection attempt because the authentication phase failed. The role does not exist, the password is wrong, or the pg_hba.conf file has no matching entry that permits this user/database/host combination.

Why it happens

1Wrong password or no password provided for a password-authenticated role
2The role (user) does not exist in pg_authid
3No matching entry in pg_hba.conf for the combination of user, database, and client IP
4Connecting to a database the role does not have CONNECT privilege on
5pg_hba.conf uses "reject" for the matching entry

How to reproduce

A client attempts to connect with a non-existent role or wrong password.

trigger — this will ERROR

-- From psql command line:
-- psql -U nonexistent_user -d mydb
-- Results in: FATAL: role "nonexistent_user" does not exist

-- Or within a session:
SET ROLE nonexistent_role;

FATAL: role "nonexistent_user" does not exist -- or FATAL: password authentication failed for user "alice" -- or FATAL: no pg_hba.conf entry for host "10.0.0.5", user "alice", database "mydb", SSL off

Fix 1: Create the role and grant connect privilege

When the role genuinely does not exist and needs to be created.

fix

CREATE ROLE alice WITH LOGIN PASSWORD 'securepassword';
GRANT CONNECT ON DATABASE mydb TO alice;

Why this works

Postgres stores roles in pg_authid. The authentication phase calls ClientAuthentication() which checks pg_authid for the role name before proceeding to the password check. Creating the role adds the entry; GRANT CONNECT sets the privilege checked during connection startup.

Fix 2: Add or fix a pg_hba.conf entry

When the role exists and the password is correct but the host is not authorised.

fix

-- Add to pg_hba.conf on the server:
-- host  mydb  alice  10.0.0.0/24  scram-sha-256

-- Then reload:
SELECT pg_reload_conf();

Why this works

pg_hba.conf is read top-to-bottom; the first matching line determines the authentication method. After editing the file, pg_reload_conf() sends SIGHUP to the postmaster, which re-reads pg_hba.conf without dropping existing connections.

What not to do

✗

Set pg_hba.conf to "trust" for all connections to silence authentication errors

Why it's wrong: Allows any client to connect as any user with no password, completely bypassing authentication.

Version notes

Postgres 10+scram-sha-256 authentication method introduced; older versions used md5 only. SCRAM is strongly preferred for new deployments.

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

📚 Feature docs: https://www.postgresql.org/docs/current/client-authentication.html

🔧 Source ref: src/backend/libpq/auth.c — ClientAuthentication()

📖 Further reading: The pg_hba.conf File

Confidence assessment

✅ HIGH confidence

Well-documented and stable. The authentication pipeline and pg_hba.conf format are consistent across all supported versions. Edge case: cloud-managed Postgres (RDS, Cloud SQL) abstracts pg_hba.conf; use provider-specific IAM or user management instead.