Choose Your Login Provider

It’s time to go log in to the system to do the thing. You haven’t done this thing in quite a while, and when you get to the login page you’re presented with twelve options with bold buttons:

You’re not in the practice of creating accounts through OAuth to login, preferring to use your password manager, but don’t find a record of an account with for this system there; neither do you find a record of creating the account in your email. After some scanning you find a small link of light gray on white: “Sign in with email” and think to try that.

You try using their recover your password facility (which prompts for a username not an email address), but never receive an email; same with recover your username. You have a vague memory of having to reluctantly create this account through an OAuth provider because they didn’t yet support signing up via email, but you can’t remember which. You try Apple as that’s your default these days, but also remember Apple’s entry as an OAuth Provider is comparatively recent and its entry there on this list is likely solely to satisfy App Store requirements, so maybe that’s not it? You try anyway, and it tells you an account already exists with that email address and to please provide a unique email instead.

Frustrated, you proceed through the list of buttons, trying to figure out who’s got your account. Eventually you give up and contact support, who are skeptical but sympathetic, and tell you it’s Yahoo! You deleted your Yahoo account years ago. Support is again sympathetic, but they have to put in a ticket for someone to manually change your account settings. It should take about a week.

Whatever the excuse, presenting users with a list of login providers is an addition to their cognitive load, regardless of whether they use an OAuth provider or not and complicates things for people in a way that earns it a square on Login Bingo.

Having implemented nearly a dozen login processes in my career, I understand why offloading this responsibility to larger companies is an appealing option for new systems. You don’t have to deal with password resets, multifactor authentication, account security issues, et cetera, ad nauseaum, when you could instead focus on what you do well.

But if your system is to have longevity, it can and will inevitably result in the type of experience described above. If you don’t believe me, well, how much friends & family tech support do you do? Horror stores aside, and while setting healthy boundaries, I think that people who design and implement technology systems should do this type of work for people they care about: there is no better way to get an understanding of how people not steeped in computer culture think about their participation in computer systems.

It’s entirely too easy to end up in a scenario like the one described above. You may think: twelve OAuth providers! that’s ridiculous and: yes it is, but never underestimate the power of Sales wanting some strategic synergy. Once you’ve added one of these, they multiply, and getting rid of them is nearly impossible.

If you must design a login system deferring to OAuth providers, please make it easy for your end-users to rediscover which of the providers owns their account, and please make it easy and self-service for someone to migrate their account to an OAuth-less sign in.