What is the best way to integrate OAuth into an existing authentication system?

Question

I'm currently working on a project to integrate OAuth with a pre-existing, in-house auth system. We have uncovered a number of potential issues, and I'm surprised to find so little online about what I find to be an amazing feature when it works right, but a terribly annoying and even stressful feature when it doesn't.

Do you have any recommended reading that outlines issues with user experience and the OAuth process? Personally I have run into issues with the Spotify / Facebook integration, and am hoping there is some research into what went wrong there, or in similar scenarios.

Here's just a few of the scenarios that I'm thinking through:

If I'm already registered as [email protected] and I hit the "login with Google" button we plan to then merge their accounts. They could then login with their previous password, or login by pressing that button again.

Cool. That makes sense.

If I'm already registered as [email protected] and I hit the "login with Google" button, the accounts will not be merged. Google ignores periods and pluses . + in your email, but we can't expect a user to know this. Since our existing auth system treats [email protected] and [email protected] as unique, this seems like a great way to lead a user to confusion when their accounts aren't merged.

This has a range of issues surrounding merging and unmerging accounts. What seems like the best solution for this case?

A brand new user registers with OAuth. They are not prompted to have a username / password. They later decide they don't want us to have access to their information in Google and they want to unlink.

How should the unlink be handled? Since they don't have a username or password, how should they be able to log in?

A user is registered with [email protected]. They forget this and they press "login with Google". Now they have two accounts with two emails. They want to be able to access all their data on their yahoo account while still utilizing this new login method.

How can we securely allow these accounts to merge?

Answer 1

Build for the biggest experience impact

You're right, OAuth is a good system. And registration and authentication is a critical part of most digital experiences. This is not an enhancement to take lightly, but it's rarely part of the central value proposition. For that reason, it can be a tough initiative to defend.

Don't get roadblocked by your current solution — take the time to make this smooth for your users. IME with auth implementations, Engineering will be more concerned with level-of-effort and security than experience. Hold your ground.

Gmail address moving pieces

If I'm already registered as [email protected] and I hit the "login with Google" button, the accounts will not be merged.

Considering the volume of Gmail users out there, there's a good chance they make up a worthy subset of your users (confirm in your user database). If that is the case, it's worth extending your auth system to pattern match gmail addresses and deal with them the same way Google does.

Unlinking OAuth

A brand new user registers with OAuth. They are not prompted to have a username / password. They later decide they don't want us to have access to their information in Google and they want to unlink.

If you don't require username and password up front, you'll have to make it part of the unlinking process.

Two accounts, one user

A user is registered with [email protected]. They forget this and they press "login with Google". Now they have two accounts with two emails.

Unfortunately, you can't fix everything for them. The user still bears some responsibility in this whole security thing. Developing a system to merge two accounts after creation is an edge case and possibly not worth the engineering effort.

However, it is advisable to offer a feature to link an existing account to an OAuth profile. In this case, the user is presented with a call to action to "simplify sign-in" and "connect your [OAuth provider] account".