On Fri, Mar 7, 2025 at 12:29 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> This got me thinking more about the existing log connections messages
> and whether or not they are actually all "stages". The authenticated
> and authorized messages occur at nearly the same time in the
> connection establishment timeline. So it seems like they aren't really
> distinct stages. The messages contain different information and serve
> different purposes. Looking at 9afffcb833d, which added the
> authentication message, it gives the example of a database user with a
> different authentication identity. The authentication message has the
> auth id and the auth method. The authorized message has the db and db
> username.
>
> So, I would call "received" and "authorized" stages and the
> authentication ID message not a stage. I think I should not call these
> "log_connections stages" in the docs and comments and instead call
> them "log_connections options".
I think it's a valid point.
If I add a hypothetical auth method in the future that authenticates,
and then farms the authorization decision out to some slow-moving
network machinery, would "authenticated" retroactively become a stage
then? (OAuth almost does this today... but it's not quite separated
enough for me to claim it as an example.) If we call them "options"
instead, I guess we don't have to worry about shifting internals.
> That also makes me wonder if the
> "authenticated" log_connections option should actually be called
> "auth_id" or something similar.
To bikeshed the specific suggestion of "auth_id": both Peter E and
Robert have previously expressed concern that my internal name choice
of "authn_id" was too opaque, and that maybe I should have just
expanded the terms. Also, I think if one option is called
"authorized", the other half should probably be called "authenticated"
if for no other reason than symmetry. It also matches the prefix used
in the logs, for English builds.
--Jacob
