Add support for OAuth

[dvob]

Postgres 18 introduces support for OAuth authentication. This PR does implement support for it. Also see #2382

Related links:

• https://www.postgresql.org/docs/18/auth-oauth.html
• https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-OAUTHBEARER

Currently it uses OAuth SASL for authentication if the OAuthTokenProvider is configured and the server offers OAUTHBEARER.
I'm not sure if this selection of the SASL auth mechanism is too primitive? Should this be configurable as well?
On the other hand I'm not sure if it is even possible that Postgres returns multiple SASL mechanisms. If I configure SCRAM and OAUTH in pg_hba.conf it seems it only returns the first match.

Also currently tests are missing.

[jackc]

I wonder how this could even be tested? Is it possible to mock an OAuth provider or would tests need to actually spin up a real one?

[UnAfraid]

I wonder how this could even be tested? Is it possible to mock an OAuth provider or would tests need to actually spin up a real one?

We'll need a fake oidc implementation for example https://github.com/oauth2-proxy/mockoidc

And a postgres 18 with the native validation library for example https://github.com/UnAfraid/pg_oidc_validator_go

[dvob]

You don't need a OAuth provider to test the interaction between pgx and Postgres. On the client side all interactions with an OAuth Provider will be implemented in the OAuthTokenProvider function. On the server side Postgres doesn't talk to an OAuth provider either but just passes the token to an OAuth validator module https://www.postgresql.org/docs/current/oauth-validators.html.
But here you can also implement a dummy module which does not talk to a OAuth provider at all.

I think the only thing we have to test is whether the token properly arrives at the server resp. in the module. For this a dummy module could be used. I implemented such a module here https://github.com/dvob/pg_dummy_validator. Usually Postgres passes the token to the module/validator and the module returns if the token is authenticated and to which user it maps. In my dummy module I just take the token string and return it to Postgres as authenticated user (e.g. if token is app you are authenticated as app).

I suggest we copy this dummy module to testsetup/oauth_validator_module in pgx. Then in ci/setup_test.bash we run make && make install in that directory if PGVERSION is >=18. Then we have a minimal OAuth validator module and can test if the token properly arrives in the module. We could of course also change the logic and for example check for a statically configured token or something like that.

In ci/setup_test.bash we would also have to add the appropriate configurations to postgresql.conf (oauth_validator_libraries = 'dummy_validator') and pg_hba.conf (host all all all oauth validator=dummy_validator issuer=https://example.com scope=).

What do you think?

The thing which is not entirely clear to me is how you conditionally test features which are only available in PG18 like this OAuth stuff? Do we use t.Skip() based on a environment variable or Go tags? What is the default (pre 18 or the new stuff)?

[jackc]

The thing which is not entirely clear to me is how you conditionally test features which are only available in PG18 like this OAuth stuff? Do we use t.Skip() based on a environment variable or Go tags? What is the default (pre 18 or the new stuff)?

There is a SkipPostgreSQLVersionLessThan helper method.

[dvob]

There is a SkipPostgreSQLVersionLessThan helper method.

This function would already require a connection but I think the main thing to test is establishing the connection using OAuth. So I introduced PGX_TEST_OAUTH=true to enable the OAuth tests.

Further I implemented the changes described above to introduce testing for OAuth. I tested the ci/setup_test.bash with PGVERSION=18 on a Ubuntu 22 and it did work including PGX_TEST_OAUTH=true go test -v -run TestConnectOAuth ./pgconn.