On Wed, 16 Apr 2025 at 02:03, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> 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.
FWIW, I have some ideas on being able to store secrets in a server in
a safe way. I'll probably start a thread on that somewhere in the next
few months.
> 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.
Seems fine to me.
On Wed, 16 Apr 2025 at 02:03, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio <postgres@jeltef.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
