Feature Request: SASL OAUTHBEARER support for PostgreSQL 18

[manuel-j-diaz]

PostgreSQL 18 introduced native OAuth 2.0 authentication via the SASL OAUTHBEARER mechanism (RFC 7628). pg currently has no support for this mechanism, which prevents connections to any PostgreSQL 18 instance configured with method=oauth in pg_hba.conf.

Background

PG18 adds OAUTHBEARER as a third SASL mechanism alongside the existing SCRAM-SHA-256 and SCRAM-SHA-256-PLUS. When a client connects to an OAuth-configured server, the server advertises OAUTHBEARER in its AuthenticationSASL message. The client must then conduct a multi-step SASL exchange, either:

• Running a full OAuth flow (e.g. Device Authorization Grant, RFC 8628) and presenting the resulting bearer token, or
• Presenting a pre-fetched bearer token directly in the initial SASL message

Relevant PG18 docs: https://www.postgresql.org/docs/current/auth-oauth.html

Why the existing password callback isn't sufficient

The dynamic password callback added for AWS RDS token auth gets conceptually close, but isn't a workaround here. Even if a valid bearer token were returned from the callback, pg would attempt to use it in a SCRAM exchange. The server expects OAUTHBEARER SASL messages instead and will reject the connection at the protocol level.

What's needed

• Recognition of OAUTHBEARER in the server's advertised SASL mechanism list
• Implementation of the SASL OAUTHBEARER message exchange
• New connection parameters for oauth_issuer and oauth_client_id (mirroring libpq)
• A hook or callback for the caller to supply a bearer token (fetched from user's IdP)

References

• RFC 7628 — SASL Mechanisms for OAuth
• RFC 8628 — OAuth 2.0 Device Authorization Grant
• PG18 OAuth auth docs
• PG18 libpq OAuth client docs
• PG18 SASL protocol details