On Fri, Sep 26, 2025 at 10:41 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> > Let me try to take a closer look at Okta here on my end. (Might take a
> > while; there are a bunch of Okta custom policies in play, I think,
> > which I am not familiar with.)
>
> I tried a few more things with Okta, but I wasn't able to convince it
> to show me the scope screen every time. There might still be some
> setting somewhere, but I couldn't figure out where.
(I'm also stuck, with my own org policies preventing testing for now :/ )
> > Scopes are a central part of OAuth design. You may not ignore them.
>
> I'm not saying that I want to ignore them, I check them properly in
> the validator code. But users can configure postgres not to require
> any specific scope, it's their choice.
They can. And your validator should complain about that, and refuse to
let anyone in, if it doesn't know how to authorize the clients.
> Postgres doesn't stop with an
> error if I just specify "openid" as the required scope in pg_hba.
If your provider hypothetically gave you a way to authorize a client
out-of-band, I don't think we should stop you from doing that;
providers can put all sorts of information into these tokens. But
you'd need to 1) have a way, and 2) provide configuration for that on
your end, and 3) not just allow the connection by default if the user
doesn't put effective scopes into the HBA.
> PKCE was originally intended for client side, but it is also used on
> backends, which is a similar setup to the postgres server-client. It
> would be possible to implement a flow such as: <snip>
I don't think we should depart from the RFCs. That's going to make it
difficult for people to figure out what's going on and audit our code,
and it isolates us from the ecosystem instead of making us part of it.
Thanks,
--Jacob
