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
