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?

  • What flow are you using? I suspect this is fine if you are using something besides the implicit flow but I'm not even sure that this will let you retrieve the email. Commented Jan 22, 2022 at 2:23

1 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.

  • There's some excellent considerations there. Regarding your point suggesting sending a confirmation link to their email address, I think that is useful where Facebook is the OAuth provider, as Facebook is not necessarily the email account provider. If the user in control of the Facebook account did not have access to the email account (e.g. if the Facebook account is hacked, but the email account is not) then this is a worthwhile safety. In the scenario where Google is the OAuth provider, the user in control of the Google account already has access to the email, so this is less useful here.
    – gbro3n
    Commented Feb 13, 2017 at 9:20
  • 1
    Yes, though I was thinking more in the direction of how to avoid having to trust anything besides the subject identifier in the identity token. The important point, I think, is that with the linking via e-mailed url scheme, you can move the responsibility for making sure you have the right e-mail address entirely to your side (how you verify is another question) - you don't need to trust the e-mail address as sent in the identity token, because you never use it at all, so you're not dependent on any given IdP's practice of handling verification of their e-mail addresses. Commented Feb 13, 2017 at 10:54
  • 2
    Which reminds me: Be aware that access to a Google account doesn't necessarily mean access to the e-mail address registered with it. For example, I have a Google account registered to a private e-mail account. The two accounts are completely separate. Google did verify the e-mail, though. Commented Feb 13, 2017 at 11:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .