PGConf.dev 2026 OAuth Working Group

From PostgreSQL wiki
Jump to navigationJump to search

Notes by Jonathan K, edited by Jacob C.

How we got here

18beta introduces 

- OAUTHBEARER SASL mechanism
- one CLI friendly client flow (Device authz)
- one global flow replacement API
   - no connection string control
   - no psql support
   - no per-connection control
- no caching
- one token validator API
- no server validators

PG18 introduces 

- runtime-loadable plugin (private ABI)
- isolation from libcurl dependencies

The post-beta split created too many callbacks and abstraction layers. Had to resurrect an old abstraction layer from beginning of the journey that became a private ABI. Wasn't able to repair until PG19beta: 

- public API for runtime flow plugin
- QoL improvements for devs
- ability for validators to set per-HBA config
- no per-connection control
- no psql alternative flows
- no caching
- no server validators

Challenges are dev timeline:

  • Sep PG18 released
  • Dec - user feedback begins
  • March 2026 - final PG19 CF

What to focus on for PG20?

Daniel G - token caching

Jonathan K - minimizing the steps for a user to integrate w/OAuth (requires driver authors to integrate with it); also making it easier to work with server validators

Daniele V - was surprised at how he had to build from its own service. The flow is implemented within the clients but not the server - seems like it's asymmetrical - feature is client-side and not server-side

Daniele - Once you have token auth in place, implementing device code on top of that was 6 lines of code. once you have clients and things parsing - the funnel of the global hooks - in a way if the device authentication libpq is sort of an experiment that we probably don't want to extend so much in that direction, and maybe using the token framework to give people about possibilities is the flow of higher-level languages.

Discussion on token exchange.

Cache, server validator, other flows - which comes first?

Euler T - connection pooling - started investigating that, people asked about pgBouncer + OAuth, and one of my first questions was what about caching, we're talking about several 100s of conns and the current model can't scale for it - any barriers we need to fix to support caching, and also support connection poolers with oauth?

Jacob - if we pull caching into the libpq - yes seems like a good idea, but who are we caching for? how are we caching? Need to ensure that tokens are not reused for the wrong people. Currently we don't constrain tokens - if you can copy/paste the token, you have the power of the token. We can constrain those to a private key over TLS, or DPOP which is its own layer of crypto to say "i own this token, it's mine, even if you have it you can't use it". Discussed token exchange for poolers/proxies

Figuring out exchange/caching is eventually our responsibility (not just third parties') because we do ship proxies, e.g. postgres_fdw.

Euler - like SCRAM, should we implement all of the oauth stuff in the connection pooler, so we can talk only oauth if the user wants?

Jonathan - federated authz - ownership of the role ID - role you login as doesn't need to match the user principal as all. that's what authn_id work years ago is meant to decouple. We can have multiple separate people within postgres without need to have separate accounts - working as same role to have the same permissions to do the same amount of things. (anonymous user - separating CURRENT_USER + SYSTEM_USER - check pg_class.relowner.)

Daniel G - discussing of the API calls that would make it possible for the server and the bouncers to share a validator API (the API itself is thin, but the server memory model and error handling are not shared)

Jacob - need middleboxes/proxies/etc. to have some way to say: this is a security-critical blob of base64, and I want to scope its permissions down to only this one thing. Hopefully token exchange can do this

Action Items

  • Everyone felt that token caching is something we should focus on immediately. It would take a full release cycle.
  • Being able to have a proxy handle these things is good - entangled with caching policy since it raises the same trust questions
  • Have the discussion on having validators within proxies like bouncer
Retrieved from "https://wiki.postgresql.org/index.php?title=PGConf.dev_2026_OAuth_Working_Group&oldid=43730"