How to handle OAuth2 registration where email address already exists as user account?

Question

I'm building an OAuth2 workflow that spans website and mobile apps.

I need to know if the following workflow is secure, where an OAuth2 registration is completed, but it is then found that the email address of the authenticated user already exists in the application database.

Currently in our application logic if the OAuth2 user already exists in the database, the OAuth2 account ID (e.g. Google or Facebook) is simply assigned to the user table in the database and access to the account is granted.

I have been concerned that this is potentially insecure, but thinking it through I think it may actually be OK, having considered the following:

• We have verified the user email account ourselves previously on non-OAuth2 user registration, so we know that this email account belongs to our user.

• Since comms is server to server for retrieving the OAuth2 account email, the OAuth2 provider cannot be tricked into returning a different email address, providing the same request URL is used.

• Facebook requires email address verification on sign up, and Google is the email account provider and does not allow for change of email address. So we know that the OAuth2 provider has verified ownership of the email address.

I have seen one app that requests that the user enter their account password if you sign in with OAuth2 but already have an account with the same email, but this must be pointless, as if an attacker were able to get past the authentication UI for the OAuth2 provider, then they also presumably have access to the email account (definitely in the case of Google) and so could obtain a password reset email easily anyway.

What I want to avoid doing is granting access to a user account to an attacker because they have presented an OAuth2 ID with the same email address.

Can you see any flaws in my assumptions above?

Answer 1

I'm doing the exact same thing, but with an identity provider where we indirectly control who creates an account, and with which mail address.

I can't see any faults in your thinking, but I'd still be uncomfortable.

1. You're trusting an external entity to vet your users for you. I'm aware that's the basic premise of oauth/openid connect, but you're trusting that the verification process stays the same as it is now. Do you have something in place to notify you when it changes?

2. Edge case: One user closes a facebook/google account, another one registers the same mail address.

3. Make sure you document the process by which Identity Providers must be chosen (eg that you shouldn't allow providers that don't verify). The people who know this is a cornerstone of your security model might move to other projects, and people who don't realize the consequences might want to add more IdPs in the future.

I thought about a different solution where I'd send my users an URL with a long, random element in it (like a password reset link) and when they hit it, I'd require them to sign in using oauth. This way, I'd know for sure who they were, because it was me sending them the URL link to a mail address I had verified. You could send that mail on first login attempt, so it would look exactly like a password reset, minus the actual entry of a new password - user must enter his mail address, you check whether it exists in your database and send him the login link, which will link his id token subject identifier to the correct user account.