zbmowrey
commented
8 years ago I have a proposed solution to this issue, but would like to discuss it; I feel like it's workable, but it doesn't make me feel super-secure.
Current behavior: On oauth callback, we check for an existing relationship with this oauth id. If found, we return the user. If not found, we create the user. This fails if the user's email is in our system, regardless of which provider was used (or even if no provider was used).
Proposed behavior: Insert an intermediary step between the oauth check and user creation, falling back to a check for the oauthUser->email. If found, update the user with this information and return. Otherwise, continue to the user creation routine.
Pro: This eliminates the wall between local accounts and oauth provider accounts, allowing a client to seamlessly switch between them with no loss of access. A user could create a local account today and login using oauth credentials tomorrow - if the email matches, the user is accessing the same account.
Con: It relies on oauth providers REQUIRING that emails be verified prior to using oauth functionality. While this is good practice -- and the three default oauths in this package do so -- extending oauth to other providers could result in a possible preemptive-registration attack (attacker registers for a service using a user's email address, then oauths to our service from that account). This attack is only possible if the attacker (a) has access to the email in question (in which case no security will prevent) or (b) is allowed to oauth prior to email confirmation.
silverbux
If a user registers using the "create an account" option and then later tries to sign in using an OAuth provider, while having the same email address in both systems, an exception is thrown since AuthController@findOrCreateUser cannot insert a record with a duplicate email address. Would it be better in this case to return to the login screen with an error indicating that the user already has an account?