rubber ducking session - multiple oauth2 login providers
stream-of-consciousness techi'm trying to suss out how a sane oauth2 social login flow should look like.
preconditions:
we have a table mapping our provider-specific unique id, to the id / primary key of our own user entity.
| provider_key | user_id | provider_name |
|---|---|---|
| 10934ABCD14322701XXXX | ab99c5ff-16ed-4ea4-a18b-7c78e6f8f93b |
initial signup is via social login #
if provider_key is not found;
-
use the oauth2 client from our backend and pull the profile details from the provider.
-
if there is already a user entity with the given email:
- simply point this
provider_keyto the existing user???
- simply point this
-
else:
- create a new user on the fly by inserting into our database (including email if it exists).
if provider_key is found:
- this implies that it has to be associated with a
user_id. proceed to login.
initial signup is via traditional / email #
- check if email and username is already present in the users table. suggest to reset password, etc.
(dis)connecting additional social accounts #
- disallow disconnecting if email is null (or else there would be no way to login)