QuickBuild supports external authentication mainly through Active Directory and LDAP; Jira and TeamForge are available as options, yet there isn't any documentation for either.
OpenID Connect (OIDC) authentication becomes possible when QuickBuild runs behind a Reverse Proxy that operates as a Relying Party protecting some part of the backend content. The need to preserve Anonymous Access and Internal Authentication places heavy restrictions on what can actually be protected.
This implementation sacrifices the Self-Registering functionality to repurpose it as a protected authentication/callback URL, and to gain its UI links. Related requests are diverted to the chosen OIDC provider, and corresponding callbacks return with an authentication header that determines the user's Login Name for Single Sign-On.
The reverse proxy needs to ensure that all other requests coming to it are stripped of this authentication header; the authentication/callback URL is already protected from tampering.
QuickBuild has to trust the authentication header from some specified IP address. Surprisingly, localhost cannot be trusted because of its potential for Privilege Escalation: already authenticated users can find out who the administrators are and thereby know their Login Names - and they don't even need RESTful API Accessible, Script Allowed or inherently dangerous permissions like EDIT_SETTINGS, CREATE_SCRIPT and RUN_BUILD, to authorize their RESTful API calls with the authentication header, from shell commands executed locally as the QuickBuild process user, via QuickBuild scripts that any user can insert even without any permissions. Since localhost requests bypass the reverse proxy, there is no way to strip them of the authentication header.
Containerizing the reverse proxy gives it a distinct IP that can be trusted, and even a possible Binding Address for QuickBuild; that would force all requests, including RESTful API calls from the server build node, to go through the proxy. This wouldn't give any additional security, since localhost authentication headers are already not trusted.
My Setting normally allows users to change their Login Name. This causes problems for any external authenticator. Using Single Sign-On has forced the reverse proxy to disable Login Name changing as a security risk: it could be used to secretly initialize the accounts of still unregistered colleagues with preset passwords. If someone's Login Name still needs to be changed, administrators can do that from User Management.