On Wed, 16 Apr 2025 at 02:03, Jacob Champion <jacob.champ...@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.champ...@enterprisedb.com> wrote: > > On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio <postg...@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
