Feature Request: SASL OAUTHBEARER support for PostgreSQL 18

未指定文件、测试或入口点。先从 RFC 7628、PostgreSQL OAuth authentication、libpq OAuth client 和 SASL protocol 的参考资料开始，然后检查现有的 SASL 和 password-callback 实现。完成的标准是：正确协商 OAUTHBEARER，定义 OAuth 连接参数和 bearer-token hook，并且 PostgreSQL 18 OAuth connections 能够正常工作。

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