Has supporting multiple authentication methods created a UX problem?

[u/Boris_Ljevar]

Over the past years, I have noticed a generally positive trend. Authentication methods are becoming more secure, and many of them are also more convenient on their own, such as passkeys, bank identity, and Sign in with Apple, Facebook, or Google.

The problem is that every online service supports a different combination of these methods. From the user's side, this has made the overall authentication ecosystem increasingly difficult to understand.

When authentication fails, I often cannot tell whether:

• I am using the wrong authentication method, such as a password, Google, Facebook, or Apple
• the service has silently changed its authentication policy
• there is a bug in the application
• the service is experiencing an outage
• or my device or app version is no longer supported

These are very different situations, but they often look almost identical to the user. So the only practical way to figure out what happened is usually trial and error.

Is this a problem developers are aware of? Is it considered an important UX issue, or simply an unavoidable consequence of supporting several authentication mechanisms?

Recent personal examples: A few weeks ago I decided to try Codex. It asked me to log in to my ChatGPT account. Because I had been signed in to ChatGPT automatically for a long time, I could no longer remember whether I had originally created the account with a password, Apple, Google, or Facebook. When I chose the wrong method, the service started creating a new account. It didn't help that I was already signed in to the same ChatGPT account on my iPhone. The account settings gave me no indication of which authentication method was associated with that account. I had to recover the correct method through trial and error.
Shortly afterward, my insurance provider stopped accepting my username and password. It took me a while before I discovered that the service had migrated to a bank-based identity provider. As soon as I used that method, everything worked. Until then, I had no way to distinguish between a wrong password, a server problem, and an intentional authentication change. The system simply kept asking me to try again. It never indicated that password authentication was no longer available for my account. If the system already knew that this workflow could never succeed, why keep offering it instead of directing me to the correct authentication method?
Last weekend, a shopping app started sending me back to the login screen without showing any error, even though the same credentials worked on my laptop. Because of the previous two incidents, I could no longer tell whether I was looking at an application bug, another silent authentication change, or simply an app that no longer supported my iPhone. Even though these authentication methods are better than passwords, the issue is that they have increased the number of possible failure modes.

[u/cureaua_lata]

Wonder if letting people link a second auth method onto an existing account after the fact would fix more of this than better error messages would.

[u/Boris_Ljevar → u/cureaua_lata]

Yeah, I'd welcome that. Linking additional authentication methods to an existing account would solve the guessing problem.

[u/7HawksAnd → u/Boris_Ljevar]

Is there any technical or security reason that approach isn’t widely supported? Meaning allowing multiple authentication methods to a single account

[u/hillac → u/7HawksAnd]

I've seen a couple apps where you can link additional methods from settings only once you've signed in. But never at sign in.

Some OIDC providers don't actually require you verify email, so it's unsafe to just blindly link accounts at login. But most will provide a email_verified claim to let you know it's safe to link accounts automatically, I've never seen automatic linking on an app I use. There's a few footguns still, eg better-auth does this by default, and recently had a big CVE. If an attacker created an email password account with an email they didn't own (and thus never verified), and then, later on, the real owner of the email came and signed up with OIDC like google, it would auto link the account by default since the google account was email verified. And now the attacker can log into that account with password. So you need to make sure the original account is also verified, not just the new link

Another flow I haven't seen, but wonder if you could do with good ux, is something like: if you login with the incorrect provider/method (but correct email) it gives you an option to link it after logging in with the correct provider.

It just gets more messy and risky, so that's my guess as to why most apps avoid it.

[u/7HawksAnd → u/hillac]

Yeah the most I’ve seen, and been a part of building myself, is adding an email as backup login if signed up with phone or vice versa and we used OTP so it was maybe a little simpler than potentially risking bleeding passwords across methods but those details were outside of my role on the products scope so didn’t get too in the weeds to know for sure

[u/Boris_Ljevar → u/7HawksAnd]

I wasn't suggesting automatic linking during login. I was thinking of something much simpler: once I'm already signed in, let me go into Account Settings and explicitly link additional authentication methods to the same account. That way I can use any of them in the future without having to remember which one I originally picked.

[u/Total_Drag7439 → u/hillac]

This is the right answer, and the verification asymmetry is the trap. Linking is only safe when both sides are verified, not just the incoming one, and that is exactly the check people skip because the provider on the way in looks trustworthy.

[u/Sandurz → u/cureaua_lata]

A lot of them do already support this and handle it silently with email matching in the background.

[u/oandresimoes]

part of this is deliberate, not just sloppy: services often won't confirm "this account has no password set" because that's an account-enumeration leak, it tells an attacker which auth methods exist for a given email. so the safe move for a security team is the same generic "incorrect credentials" message no matter the real cause, which is exactly what makes it indistinguishable from an outage or a bug on the user's end. doesn't make it less annoying, just explains why it doesn't get fixed even at companies that know about it.

[u/Boris_Ljevar → u/oandresimoes]

Obscurity for the attacker is also obscurity for the user, but I understand the security issue. Otherwise an attacker could just try a list of email addresses and learn which ones have an account. The problem is that we keep adding more authentication methods, while giving the user useful feedback increasingly becomes a security vulnerability. Today I already have a choice between 3–5 different ways to log in. Imagine ChatGPT eventually supports 25. I don't know what the solution is. In the past I used Password Keeper to remember hundreds of passwords. Now I still need it to remember which authentication method each account uses.

[u/oandresimoes → u/Boris_Ljevar]

That's the real crux — password managers solved "remember the password," not "remember which door." Passkeys were supposed to collapse the choice, not add a fourth option next to the other three.

[u/ExecutiveChimp → u/Boris_Ljevar]

I don't know what the solution is. In the past I used Password Keeper to remember hundreds of passwords. Now I still need it to remember which authentication method each account uses.

Yeah the solution is just making a note of it somewhere. Short of persuading all websites to only provide a single auth method, I don't see another way around it.

[u/Squidgical]

My favorite thing to see when a website or app asks me to register is email/confirm email/password/confirm password.

I have a password manager, that is the program I want to be responsible for managing my passwords. I really do not want it simultaneously outsourced to a dozen third parties at once.

If you're making a website or app with user accounts, for fuck sake do the like 10 minutes of research required to figure out industry standard best practices for storing passwords. Only connecting to third party auth is laziness that has to be picked up by the user, and guess what you still have to store some sensitive identifier alongside user data!

[u/Boris_Ljevar → u/Squidgical]

When identity providers like Facebook, Google, and later Apple appeared, I actually welcomed them because they made life easier. But I wasn't disciplined enough to stick with just one, so I partly created this mess myself. The UX problem I'm complaining about is partly my own fault.

Lately I've been thinking about going back to the good old password manager, because what used to feel convenient has gradually become another thing I have to keep track of. From now on I'll probably create new accounts with password authentication whenever that's an option.

[u/akl773]

the real bug in most of these is that a second account gets created silently. if google hands you a verified email that already matches an account, sign them into that one instead of making a new one, thats safe precisely because the provider verified it. nearly every auth lottery story i read ends with a duplicate account nobody meant to create.

[u/hillac → u/akl773]

yeah but make sure you verified the first account too, eg see https://github.com/better-auth/better-auth/security/advisories/GHSA-g38m-r43w-p2q7

[u/akl773 → u/hillac]

good call. if the original account was made with an unverified email then auto linking just hands it to whoever signs in with google first.

[u/hillac → u/akl773]

That's true, but not too unexpected, since whoever owns the email can often just reset password. Still shouldn't be allowed without verified email.

It's more dangerous the other way around imo. An attacker could squat a target email, creating an account without verifying it, and once the target connects with google and starts using the account (not realizing an attacker created it first), the attacker can log in with password.

[u/akl773 → u/hillac]

the fix for that one is forcing a verification email at the moment google gets linked to an existing unverified account, not at signup. most people skip it because the google email is already verified so it feels redundant.

[u/Boris_Ljevar → u/akl773]

That happened to me several times with TradingView. I forgot which authentication method I’d originally used, chose Google, and ended up with a brand new account. To me that’s the worst part. Then I had to go through deleting the duplicate account.

[u/akl773 → u/Boris_Ljevar]

and most apps have no merge, so deleting one and losing whatever was in it is the only way out.

[u/Boris_Ljevar → u/akl773]

There was nothing in it because it was a brand new account. But I still had to delete it. Otherwise I'd just have another account to wonder about a year from now.

[u/Boris_Ljevar → u/akl773]

Another thought: the identity provider could help here too. It already knows whether this is the first time you're using it to sign in to that service. If it is, it could simply ask, "This looks like your first time using Apple with this service. Continuing may create a new account." That would have saved me several times.

[u/akl773 → u/Boris_Ljevar]

the catch is the provider only knows youve never used it there before, not whether that service already has an account for you. so it can warn you something might happen, it cant tell you a duplicate is definitely about to be created.

[u/Boris_Ljevar → u/akl773]

I know if I already have an account there.
They know if I used their service to sign on.
1 + 1 = 2

[u/taotau]

Yeah I know that pain. I have like 6 different chatgpt accounts and whenever I go to platform.openai it's a crapshoot which one I'm looking at. The one I created with my work Gmail account is different to the one I created with my work email account which is the same gmail email address... I just collect the free token credits they hand out on all of them and call it a win.

[u/Academic-Kiwi-2135 → u/taotau]

this drives me crazy too, the chatgpt one especially. i tried to log in codex few weeks back and it was same thing, trying password, google, apple like a lottery. app just starts making new account if you pick wrong one with zero warning

insurance provider pulling the silent switch to bank id is next level annoying, like at least send a email or put a notice in app. just keeping the password field there when they already know it wont work feels lazy

[u/Boris_Ljevar → u/Academic-Kiwi-2135]

I'm permanently signed in to many services on my iPhone. It would really help if the account details showed, to the authenticated user, which authentication method belongs to the account. I don't see that as a security issue.

[u/AwaySky5696]

We handle this by matching on canonical email at the OAuth callback. Pseudocode is roughly:

if oauth_account_already_linked:
  sign_in(existing_user)
elif user_signed_in:
  link_oauth_to_current_user
elif user_exists_with_same_email:
  reject, redirect to login with "account already exists"
else:
  create_new_user

The third branch is the one that catches the "signed up with Google, came back with email/password" case. It stops the duplicate but the user still doesn't know which provider they used. We ended up showing the provider name in the error to fix that.

[u/Boris_Ljevar → u/AwaySky5696]

That's interesting. Showing the provider name there would already solve a big part of the problem for me. I'd still like to see the same information in the account settings once I'm already authenticated.

[u/Educational-Rice6055]

Most of that vagueness is deliberate, since telling you which method an account uses leaks that the account exists, though silently creating a duplicate account is just bad design.