-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth authentication with existing normal account when account user is email #137
Comments
It looks like the current behavior is:
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:
Thoughts? I enjoy the opportunity to talk this through. |
AH! Well thought! And thanks for the quick response, awesome! 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?) |
OR, we could approach this from another angle:
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? |
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. |
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.
Yep the same OAuth endpoints will link identities if the user is logged in. |
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 |
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. |
Cool, I've opened Issue 138 |
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).. |
Looks like the documentation could be better on that resolution. Thanks for discussing! |
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?
The text was updated successfully, but these errors were encountered: