Re: [oauth] SASL mechanisms

On Tue, Nov 25, 2025 at 9:40 AM Nico Williams <nico(at)cryptonector(dot)com> wrote:
> > I could see us eventually pulling out the user's claims (whether from
> > Kerberos or OAuth, or maybe generically mapped from an identity) into
> > a central API. That way validators wouldn't have to reinvent the wheel
> > each time.
>
> But I want it _now_ not eventually :)
>
> (And... I don't have time to contribute this, plus I've tried to
> contribute to PG before and got my patches into two commitfests, but the
> amount of energy needed to contribute to PG is too high.

Yeah, lowering the barrier to entry is a perennial topic...

> Authorization servers are external. You don't need to wait for them.

We can implement to spec, but real-world testing gets difficult if no
one else does. I'm not really comfortable blazing a trail there.

> > > Imagine that we had set-only session-level `set_config()`s, and/or ones
> > > that require privilege. Then authen. mechanisms can set a bunch to
> > > describe the credential used. And then there could be a "session begin
> > > trigger"-like function that the DB owner could specify to the rest of
> > > whatever they want done, up to and including [optionally] `SET SESSION
> > > ROLE`.
> >
> > If anyone else is reading along, I'd be interested to see what kind of
> > appetite there is for a generic mechanism like this? It sounds like a
> > decent idea to me, but I'm not sure how big the audience for it would
> > be.
>
> Please folks speak up for this! :)

Thread bump, in the hopes that we ran into the Thanksgiving lull.

Also, you may be interested in a half-baked proposal [1] to load
custom OAuth flows for psql et al.

--Jacob

[1] https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com