Re: dispchar for oauth_client_secret

On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> I don't understand why it should be a server option instead of a user
> mapping option. Having it be a server option means that *any* Postgres
> user can read its contents.

Thank you for saying something; I'd hallucinated that srvoptions was
limited to the server owner, and that's not true. It's pg_user_mapping
that has the protection.

But if you want to hide the client secret from your users, making it a
user mapping option has not made the situation better. The client ID
and secret are there to authenticate libpq (and by extension,
postgres_fdw), not the end user.

> My knowledge on the purpose is pretty
> limited, but having that be the case for something with "secret" in
> the name seems very unintuitive.

From the point of view of a proxy, whether you use a secret at all is
up to the flow in use. And for 18, the only supported flow is focused
on authorizing an actual human at the keyboard, without any token
caching, making it pretty unhelpful for FDW. A more proxy-friendly
flow would be awesome -- and/or explicit integration of the existing
builtin flow into the proxies, both safely and helpfully -- but that's
not a v18 thing. (I view it as similar in spirit to the
SCRAM-passthrough work.)

So: maybe it'd be best to disallow the OAuth options in the proxy code
entirely, so that a proxy-friendly future implementation is not
accidentally tied to decisions we made in v18.

--Jacob