OAuth authentication with existing normal account when account user is email

[martinreus]

Hey Lance and all contributors!

First of all, thanks so much for this project, looks really good.
So I gave the server a spin and started testing some stuff. I specifically set USERNAME_IS_EMAIL=true and then created an account using the signup endpoint, using my GMail address for that. All good.

Then I tried logging in using OAuth and Gmail, but got access deined because that account already existed. I would expect to be able to log in using OAuth and Gmail, since I am the owner of my account. Shouldn't this be the expected behaviour?

[cainlevy]

It looks like the current behavior is:

1. Attempt to log in to a new account
2. Attempt to link with an account in the current session
3. Attempt to create a new account

Missing here is the scenario you're describing where you link with an existing account based solely on a matching email. I admit it's not handled by AuthN because I was unsure if it was a safe algorithm for all applications.

My primary concern with this algorithm is something I'd call account injection. Suppose I register yourname@gmail.com with a password, then wait. Some time later you log in with Google using the same, and then, not realizing I have access to the account by password, you do something valuable.

The workaround for this missing behavior might be:

1. Detect OAuth failure due to existing account
2. Show message encouraging user to log in to (or recover) their account and complete the linking from their profile

Thoughts? I enjoy the opportunity to talk this through.

[martinreus]

AH! Well thought! And thanks for the quick response, awesome!
Yeah, I missed the injection scenario..

Well, I suppose that if in step 2 we reset the password (when recovering in case of a malicious user having created the account with some password) there would be probably no risk in linking the oauth account.. Also probably all access and refresh tokens will have to be revoked by the time of account recovery (is this already the case?)
Do we already have a REST endpoint from where we may link accounts?

[martinreus]

OR, we could approach this from another angle:

• User signs up
• User has to confirm account through e-mail confirmation
• User performs OAuth login
  • If not confirmed, login is denied with friendly reminder about account activation
  • If confirmed, simply link accounts

This way we avoid doing the whole recover account / invalidate access and refresh tokens, while also being on the sure side that the owner which created the account is actually owner of that e-mail..

I remember that some time ago I got an e-mail from Netflix saying that my 30 day trial account had been activated. Problem is that I never even registered on Netflix; that means that someone was hapilly using my e-mail address for that..

What do you think?

[cainlevy]

I agree, knowing that usernames are emails and knowing that an email has been confirmed would make this OAuth flow safe. The second requirement is a sticking point for AuthN currently.

[cainlevy]

Missed some other points!

Yes, resetting an account password and invalidating sessions could also make the flow safer. I wonder if the UX trade-off is worth it, considering the impact on legitimate scenarios.

Do we already have a REST endpoint from where we may link accounts?

Yep the same OAuth endpoints will link identities if the user is logged in.

[martinreus]

The second requirement is a sticking point for AuthN currently.

Can we open an issue for dealing with this? I can help if you want =) Would just probably need some directions on how to do this properly since I'm not that familiar with the codebase

[cainlevy]

Separate issue sounds good. 👍 I think there are a few important decisions to work through before getting into implementation, and I'd like the discussion to be discoverable whatever the outcome.

[martinreus]

Cool, I've opened Issue 138

[martinreus]

I think this Issue can be closed, since we have the possibility to link an OAuth account when we are logged in (thus preventing the account injection attack)..

[cainlevy]

Looks like the documentation could be better on that resolution. Thanks for discussing!