• Sourcegraph version: all versions back to 2020 and maybe more
• Platform information: all platforms

Steps to reproduce:

1. Within an identity provider such as Okta, create a user with the following example profile attributes:

name: Chris Concannon
username: chco999
email: chris.concannon@sourcegraph.com
preferred_username: chrisco

Now create both a SAML connection and an OpenID Connect connection to provide SSO to Sourcegraph. Log in via SAML with the user's credentials, then log out and log in via OpenID Connect.

Observe that the default behavior is that this single user will be created as two different users within Sourcegraph because of the differences in logic used to create the Sourcegraph username.

Expected behavior:

The user is able to log in via SSO using SAML or OpenID Connect, and the user is logged in to the same user profile in Sourcegraph.

I personally think that the order of preference to choose the Sourcegraph username should be preferred_username, username, and then email.

Actual behavior:

SAML picks, in order, the following traits to map to the Sourcegraph username: login, uid, username, ... https://demo.sourcegraph.com/github.com/sourcegraph/sourcegraph@v5.2.6/-/blob/cmd/frontend/internal/auth/saml/user.go?L7

OpenID Connect picks, in order, the following traits to map to the Sourcegraph username: preferred_username, email
https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/cmd/frontend/internal/auth/openidconnect/user.go?L45-57

At least 1 Enterprise customer has reported that their self-hosted Bitbucket Data Center code host does not correctly federate user accounts because Bitbucket creates/finds users based on the username trait from their IdP, while the OpenID Connect integration with Sourcegraph from that same IdP does not look at username at all.