Implement OAUTHBEARER to support PostgreSQL 18 OAuth flow

[vlsi]

See https://www.postgresql.org/docs/18/sasl-authentication.html

At the moment, PostgreSQL implements three SASL authentication mechanisms: SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and OAUTHBEARER

Looks like adding OAUTHBEARER support would be valuable addition to move towards short-lived tokens: https://chatgpt.com/share/68d634d4-3c14-800f-b8e1-a3e4fd5cb6d9

[artemgavrilov]

Hello @vlsi , I would like to work on this (including pgjdbc part). It seems proper way is to create generic SASLClient abstraction that will enclose SCRAM and OAUTHBEARER as they have common first round trip. But it will require pretty big refactoring, I guess. Creating just plain OAUTH client alongside with existing scram client seems insufficient to address pgjdbc needs as there authentication handled on SASL abstraction level (now it just creates scram client). Embedding OAUTHBEARER as just anther option into existing scram client seems incorrect from logical standpoint and also may be problematic as oauth has different message flow.

I would appreciate any suggestions/guidance, thank you!

[jorsol]

After thinking about this, while SCRAM and OAUTHBEARER share the same SASL framework, they differ fundamentally in their handling of trust and credentials.

A SCRAM library is primarily a cryptographic engine. It manages salted password hashing (PBKDF2), HMAC signatures, and the multi-step state machine required for challenge-response rounds.

In contrast, an OAUTHBEARER implementation acts as a transport and validation layer. It focuses on token propagation, JWT parsing, and interaction with external Identity Providers (IdP) via OpenID Connect (OIDC).

Does it make sense to implement OAUTHBEARER within a SCRAM library? The short answer is no.

While this library was built primarily for the PgJDBC use case, it is designed to be a lightweight, independent utility. Adding OAUTHBEARER would introduce out-of-scope dependencies and architectural bloat. This functionality is better suited for a separate module.

[artemgavrilov]

Hi @jorsol! Aha, that's definitely makes sense! Thank you!