Re: dispchar for oauth_client_secret

On Tue, Apr 15, 2025 at 1:48 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> If we think oauth_client_secret should get dispchar="*" UI treatment yet be a
> postgres_fdw server option, postgres_fdw code can make it so. postgres_fdw
> already has explicit code to reclassify the "user" option.

Agreed, I will add an open item.

> The documentation of dispchar likely should tell people to update
> the postgres_fdw documentation when adding a dispchar="*' option.

(Or dispchar="D".)

> It sounds like we might end up wanting to allow oauth_client_secret in both of
> ForeignServerRelationId and UserMappingRelationId, each catering to different
> oauth implementations. Is that right? (It would be fine to allow one today
> and later change to allow both.)

I think, for the short-to-medium term, it is best to think of
oauth_client_id/oauth_client_secret/oauth_issuer as a packaged triple.
You don't want to use a secret with the wrong client ID, you don't
want to send a secret to the wrong provider, and one provider's client
ID won't be recognized by another. There might be some providers that
let you issue multiple secrets per client ID, but I seem to recall
that's intended more for rotation than it is for separate end users.

(It is true that separate users could make use of separate issuers
entirely. But that's conceptually separate from allowing a user to
control the HTTP entry point of server-side libpq without OWNER
privilege on the server. I don't like that at all from a risk
management perspective, and I'd prefer that we keep oauth_issuer on
the server context. It might be safe at some point to pull both
oauth_client_id and _secret down to the user context, once there's a
use case.)

Thanks!
--Jacob