Re: unclear OAuth error message

On Mon, Jan 26, 2026 at 12:53 AM Zsolt Parragi
<zsolt(dot)parragi(at)percona(dot)com> wrote:
> I also want to add that these error messages are not that useful for
> figuring out what went wrong. In practice, the validator has to report
> more specific error messages before this happens, otherwise the user
> won't be able to figure out why we are rejecting some login.

Right.

> And if it reports an error, and stops the code flow, these won't be
> displayed at all - but then why do we have all these bool outputs in
> the validator?

In general, don't stop the code flow. We want failures to be handled
in-band [1] so that the server's communication with an unauthenticated
client is standard across validators and auth methods. (Our SASL
abstraction layer is leaky here, in the sense that mechanisms have too
much power over the network layer.)

And in general, we want to avoid leaking token information to
unauthenticated clients. The server should not act as an oracle for
people with ill-gotten tokens.

> And even the messages in the caller code are
> WARNING/LOG. The intention of the API seems to be to report WARNINGs
> for validation failures, even internal errors, so for now we added
> most error checks in the validator as that, allowing the code to
> continue.

COMMERROR (LOG_SERVER_ONLY), which is also documented in [1], is a
good bet. WARNING is fine only in the sense that it's not emitted
during authentication, but it'd be odd to see a warning for a
run-of-the-mill validation failure. (For internal errors, like "I
couldn't get the public keys", I think WARNING probably makes sense.
Or if something causes you to think that somebody is under active
attack.)

--Jacob

[1] https://www.postgresql.org/docs/18/oauth-validator-design.html#OAUTH-VALIDATOR-DESIGN-GUIDELINES