this issue is about both connecting new users to the network and adding some authentication mechanism between soju and an upstream server to automatically log in users?

Precisely. It's a pretty important accessibility concern, in our usecase, as some of the users might not be familiar with IRC etc. so it's a low-friction onboarding mechanism makes the difference between “works” and “user gives up, remains stuck on for communication within our group.”

Thinking about it, that could be implemented via a “hook” called whenever a new/unknown user connects; here, the hook would perform the token exchange flow, and populate the user's configuration with the IRCnet (using the newly-created token as OAuth2 credential)

I would be concerned about the security implications of forwarding automatically bouncer credentials to a server

I didn't mean reusing the same credentials, but rather using a token exchange flow, where the credentials provided to soju would authorize it to request (from the IdP) a credential scoped for the IRCnet. That way we get impersonation (the IRCnet considers the session to be the user's, not the soju service account's) while still only using credentials scoped to a single service at every step, and without unrestricted impersonation power.

RFC 8693 standardizes OAuth2 token exchange flows, but the concept has been around for much longer.

I'm considering hosting soju in a setting where all users entitled to use the soju instance, would also be entitled to use a local IRCnet.

As both would use the same IdP (via OAuth) it should be possible to leverate authentication-to-soju, so into soju authenticating to the IRCnet.

Would that be an upstreamable feature ?