Authentication methods have generally become more secure and convenient. Passkeys, bank identity providers, and sign-in options from major platforms can all be easier than managing passwords on their own. The problem is that different services support different combinations, and they often provide almost no guidance when authentication fails.
As a user, it can be difficult to tell whether I chose the wrong method, the service silently changed its login policy, the application has a bug, there is an outage, or my device or app version is no longer supported. These situations often produce the same generic error or simply return me to the login screen, leaving trial and error as the only practical way to diagnose the problem.
Recently, I tried to use Codex with an account I had been automatically signed into on another device. I could not remember whether I originally created the account with a password, Apple, Google, or Facebook. Choosing the wrong option started creating a new account, and the account settings did not show which authentication method was linked to the existing one.
Soon afterward, my insurance provider stopped accepting my username and password because it had migrated to a bank-based identity provider. The old login form remained available and gave no indication that it could no longer work. I had to discover the new method by trial and error.
A shopping app later began returning me to the login screen without an error, even though the same credentials worked on my laptop. At that point I could not tell whether the problem was an application bug, another authentication change, or lack of device support.
Is this recognized as an important UX problem, or is it considered an unavoidable trade-off of supporting multiple authentication mechanisms? How should services prevent duplicate accounts, explain which login method is associated with an existing account, and still avoid exposing information that could help attackers enumerate accounts?
5 Answers
Third-party sign-in is not automatically better UX. It can be convenient when someone consistently uses one provider, but choosing Apple for one service, Google for another, and passwords elsewhere creates a second kind of credential-management problem. A password manager can track both passwords and the login method associated with each account, so using a normal account with a strong generated password is still a reasonable choice when available.
Some of the vague messaging is intentional. Saying “this account uses Google” or “no account exists with this method” can reveal whether a particular email address has an account, which creates an account-enumeration risk. That is why security-conscious systems often use the same generic response for incorrect credentials, nonexistent accounts, and unsupported methods.
That explains the ambiguity, but it does not justify every poor experience. Services can still give useful guidance after the user has authenticated, show linked providers in account settings, send notices when login policies change, and avoid leaving a known-invalid login form active forever.
A major improvement would be preventing silent duplicate-account creation. If someone signs in with a verified identity provider and the canonical email matches an existing account, the service should avoid creating a second account. It could either sign the person into the existing account after appropriate verification or explain that an account already exists and guide them through linking the provider.
For users who are already signed in, adding another authentication method should be straightforward. Linking a password, passkey, or identity provider to the current account would eliminate much of the login-method guessing.
Exactly. If a new provider is being used for the first time, the service could warn that continuing may create a separate account. That would prevent many accidental duplicates.
The best systems treat authentication changes as a user-facing migration rather than an implementation detail. Keep existing sessions working where possible, announce the change in advance, explain the new method when the old one is attempted, and provide a recovery path. Generic errors may be necessary at the unauthenticated boundary, but silently creating accounts or repeatedly presenting a method that the system knows cannot work is avoidable design failure.
Showing the relevant provider name when it is safe to do so would solve a lot of this. One practical flow is: if the OAuth identity is already linked, sign in; if the person is signed in, offer to link it; if an account with the same verified email already exists, stop and direct the user to the existing login or recovery flow; otherwise create the account.
The provider name can be shown in the authenticated account settings, and possibly in a carefully designed recovery flow. Services should also notify users when they migrate from passwords to a bank or other identity provider instead of silently leaving the old form in place.
Even an error saying “This account was created with Google” would be much better than making users try every option, as long as the service has verified enough information to show it safely.
That makes sense from a security perspective, but it also means users need somewhere else to find the information. I would really like to see the linked authentication methods in my account settings, along with clear warnings before a new method creates another account.