#Best practice for multiple linked external accounts in auth?

29 messages · Page 1 of 1 (latest)

wintry carbon
#

Hey guys, have ran into a small issue recently regarding auth. I have an app where a user can log in with google, log in with github, etc.

So, if a user with [email protected] makes a google account that creates user_id 1234

and then that user tries to log in with github that is also tied to [email protected], how would the best way to handle this be?

I assume making a new account for the user is bad, but also checking by email is bad (what if the one using github [email protected] is malicious/someone else).

I am thinking to have it so there is an external_account table which holds the provider (e.g. GOOGLE, GITHUB), and then user_id that points to user:

So like

user = {
id: 1234,
email: "[email protected]"
}

external_account_1 = {
id: "some-google-id",
user_id: 1234,
provider: GOOGLE,
provider_user_id: "users-google-id-thing"
}

external_account_2 = {
id: "some-github-id",
user_id: 1234,
provider: GITHUB,
provider_user_id: "users-github-id-thing"
}

But i genuinely don't know how the flow would look. From a UX perspective, i've never had to myself do a "first login with your existing google account then login with github to link it" so i don't think this is the best way.

Should i just not allow them to make a github account if they already made a google account with the same email? And just say "user already exists with this email, please log in with google instead".

Should i let them after auth with google go to a page where they can also "link github"? But not during login just after they login with google they can themselves go to the link accounts page?

#

Should i have it like

User tries to auth with github ->

Google account already exists ->

Server stores the github credentials in a pending_external_account ->

User is prompted to log in with google ->

User logs in with google and sends google creds ->

Server verifies creds, inserts the pending_external_account data into external_account ->

Server deletes pending_external_account row ->

Server returns ok ->

User sees "Successfully linked, please relogin with github" ?

quasi hearthBOT
#

-# @wintry carbon Whoa, 152 days! Your streak is legendary! You've earned a 2x BYTES bonus for your epic run! Keep coding!

wintry carbon
#

screw it one provider per email

#

email already registered error if they try with github

fair elbow
#

you set a provider type in your types and include one for each login provider

first one they sign in with, assign it

google: [email protected]

ok later they sign in with facebook provider but the email still matches,

log them in anyway

#

if you want them to choose accounts to be equally linked the make a connections table and ask them to sign in with each provider they want, and whenever they login check against that table

wintry carbon
fair elbow
#

isn’t it already that way everywhere? If someone compromises your Facebook, they can log into everything and try to get into your accounts.

#

when using social media for login, you’re at the mercy of that provider’s ability to sign in that user

#

it’s always the users responsibility to protect their security on their account

#

or am I misunderstanding your question?

wintry carbon
#

Though i guess if someone hacked my facebook and made a new account on a service i never signed up for with any provider then it would have my data anyways

#

Ok fair enough i see your point

wintry carbon
fair elbow
#

i’m only talking about apps that let you sign in with that specific Facebook account for example, if you sign into railway with GitHub and I hack your GitHub, I can sign into your railway

#

but that’s not because railway did anything wrong or picked a bad authentication pattern

#

there will always be bad actors that try to circumvent what you build. Assess the situation at the time you are building it and make the best decision you can. That’s really all you can do.

In practice, it’s best to use a third-party for the authentication like fire base or okta

wintry carbon
#

No yeah i am genuinely confused why i thought that was a bad idea

#

Thank you yuno this is very enlightening

#

Holey moley

wintry carbon
fair elbow
#

they handle everything with related for you

#

auth***

wintry carbon
#

Oh man i should have just used firebase

#

Man i was validating my own subs and stuff

#

I feel so dumb😆😆