search

flarum / issue-archive

0 stars 0 forks source link

OAuth2 Login/Registration Flow #236

Open tankerkiller125 opened 5 years ago

tankerkiller125 commented 5 years ago

Bug Report

Current Behavior The current behavior relies on email addresses to compare user authentication, this means that if a user uses an OAuth2 account that doesn't use the same email as a previous account that user ends up with two accounts.

Steps to Reproduce

  1. Register an account the normal way (using one email)
  2. Logout
  3. Login using an OAuth2 provider that uses a different email address
  4. See error

Expected Behavior We should do this exactly the same way all other systems do this as described:

User Has Account Already (E-Mail Matches)
  1. User chooses to sign in using OAuth2 for the first time
  2. Server detects that the email from OAuth2 matches that of a current user
  3. Server request password for the found user account
  4. User enters the password correctly
  5. Server connects the accounts and never request a password going forward
User Has Account Already (E-Mail Doesn't Match)
  1. User chooses to sign in using OAuth2 for the first time
  2. Server can not find a pre-existing account
  3. Server displays a prompt asking if user wants to sign in using existing account or register a new one
  4. User chooses to sign into account
  5. User successfully enters credentials
  6. server makes the association and never prompts for forum credentials again when using OAuth2
User Does Not Have Account
  1. User chooses to sign in using OAuth2
  2. Server can not find pre-existing account
  3. Server displays a prompt asking if user wants to sign in using existing account or register new one
  4. User chooses to register new account
  5. Server request required information not provided by OAuth2
  6. User completes sign up
  7. Server makes association between the newly registered account and the OAuth2 provider

Screenshots If applicable, add screenshots to help explain your problem.

Environment

Possible Solution From my understanding from a forum post I made the code to store additional data from OAuth2 providers has already been implemented. It should be possible to I believe that this is mostly a UI change to make this change function. I don't know exactly what needs to happen in order to make this function in the backend or for that matter if this can be done using a plugin.

tankerkiller125 commented 5 years ago

Additionally if this isn't so much a bug but a feature request, I'm sorry in advance for using the wrong format. This just seems more like a bug than a feature thing to me since Flarum is the only service I know of that doesn't allow different emails between OAuth2 providers.

franzliedke commented 4 years ago

Server displays a prompt asking if user wants to sign in using existing account or register new one

The base would be an option to connect SSO providers directly from the user's profile when logged in. Your proposed workflow would basically be a login followed by a redirect to that page.

So, from my perspective, adding that section to the user's profile would be the more important first step here.

askvortsov1 commented 4 years ago

In addition to the proposed UX change for adding accounts, I think as much as possible of the code for registering / logging in users via external login providers should beoved to API from Forum. One issue though: if the username isn't provided, there needs to be a way to have the user enter that. This means that some amount of code will need to be kept in forum. However, I still think that the actual logging in and registering should be handled via an API endpoint. Any ideas for more elegant ways to handle username providing?

tankerkiller125 commented 4 years ago

Currently we use data provided by the OAuth2 provider to guess/recommend a username, I would recommend that we keep that feature.

askvortsov1 commented 4 years ago

I'd agree with that, and I think that the login provider system we have now, although it could use some cleaning (particularly in how it deals with frontend, I don't like that the login modal needs to be open for it to work) could set a good base for expansion. I'd say that there should be 1 login and 1 registration controller, and the login driver should be chosen based on a GET parameter to the endpoint. If missing, the system should go with a "default" login provider (the username password system)