Third party login brainstorming

[rishabhpoddar]

Moving the discussion to https://www.notion.so/Social-Login-972e603a6a814f209f6f53e4c025a278

Random notes:

• Account consolidation
• Should users create a new password on using social login?
• https://twitter.com/Cruip_com/status/1148244507969904641
• Initial providers:
  • Google
  • Facebook
  • Github
  • Apple
• What happens in case of a user using one social login, that login is removed, and then they want to sign in with their email ID, but have no password...
• What happens in case a user signs in with fb, and then tries to sign in with google with the exact same address?
• What happens if a user signs in with a provider, but then updates their email on google?

[kant01ne]

Open questions:

• Can we use passport-js?

• Do we provide tutorials/docs to help people generate their clientID, clientSecret, callbackURL

• Do we make a difference between sign-in/sign-up when using social login. i.e. If user uses "login with twitter" but has no account, do we create one or do we redirect to signup? I've seen companies redirecting to signup, I thought it was useless but there might be a good reason for that?

• Do we assume that an email is verified if connect with social login? Is there cases where you can create an account on a social media without verifying your email address and use for oauth? It is our responsibility to integrate only with those that are secure so we have to check that first before adding a new social media. See gitlab https://hackerone.com/reports/922456

• Email verification page: if we consider that social login means verified email, can we add social login email verification to the "Email verification" screen, if the user created their account with email/password in required email verification mode.

Attack vector 1: Pre account creation account takeover

Steps 1/ Attacker sign up to App with the victim's email (victim@gmail.com) using email password 2/ Victim creates an account using social login using their victim@gmail.com address. 3/ Attacker uses email password to login and has account takeover

Mitigation Mitigation 1: Disable email/password authentication once the user has used social login. Pros: It does not disrupt sign up flow. Cons: Victims have no idea that someone tried to create na account with their address. Their password is still set to attacker's password which might lead to an issue in the future (if social login gets removes?).

Mitigation 2: Prevent from login/sign up with social login if an account already exists. "An account already exists. Please use email/password" => Victims are forced to reset their password. Attacker can not access victim's account. Pros: Victims are aware that an account already exists for their address. Attack is impossible even after social login is removed. Cons: Disrupt signup flow

Mitigation 3: Ask already existing users who sign in with social login for the first time to reset their password. Pros: stop the attack fully. Let the user sign in Cons: Disrupt signin flow.

Attack vector 2: CSRF Attack

Depending on what we decide for attaching social login accounts to email/password, we need to make sure we use a randomly generated state argument (even when not required by social provider).

Ex: https://hackerone.com/reports/215381 https://hackerone.com/reports/111218 https://hackerone.com/reports/2228

Open redirect

We do not have to care about open redirect because we initiate the flow from the server and redirect to the server without ever specifying redirect_url in any urls (See graph below). We just need to ask our customers to set the redirect url to https://{apiDomain}/auth/callback/{social}

EDIT: Arf, I think we lost this graph because I don't have a paid version of awwapp... Would be nice to have one we can update. I'll find something to do this for free. https://awwapp.com/b/ueqz6rjumjnwt/

[rishabhpoddar]

Attack vector 1:

I prefer Mitigation 2

Attack vector 3

Agreed.

Open redirect

Actually, the redirect URL will be on the website domain, not the api domain. The flow wil be initiated from the react frontend which will redirect the user to the social login provider's frontend. That site will then redirect the user back to the react frontend (some route).. from there, we will call the backend API. So i'm not sure if this attack vector is still valid?

[kant01ne]

I had not thought we could bypass the backend because of the state parameter which I strongly thought could be done only from the backend. But actually, why couldn't we generate a random state from the browser, store it in the local storage, and validate it from the front end? It seems that it's actually a thing https://stackoverflow.com/questions/53736518/do-you-generate-a-state-parameter-back-or-front-end-for-an-oauth-2-0-request

I will have to modify the graph from above which I think we should strive to keep up to date and complete as it will help for any architecture discussion.

For open redirects, if the provider implemented their oauth2 correctly, the user can specify the route they want to redirect to, we are sure that it redirects to their website. Once we implement redirect_to url https://github.com/supertokens/supertokens-auth-react/issues/77, if we are were not careful and introduced an open redirect (which we won't :)), there might be ways for an attacker to chain both redirection to steal the oauth code.

[kant01ne]

Social Login pre account takeover, mitigation 2, does that mean the user has to keep using email/password forever if an attacker tried to hack their account? It might be ok since this is really edge case.

[rishabhpoddar]

Yea. I think it's OK

[rishabhpoddar]

Can we use passport-js?

We can seem to use it, but a couple of issues:

• This apparently requires the frontend site to redirect the user to the backend APIs (which I find very strange..)
• What will we do for other backend SDKs?

[kant01ne]

Ruby has https://github.com/omniauth/omniauth Python has https://github.com/lepture/authlib/ Go has https://github.com/golang/oauth2 They all have something.

[kant01ne]

Do we make a difference between sign-in/sign-up when using social login. i.e. If user uses "login with twitter" but has no account, do we create one or do we redirect to signup? I've seen companies redirecting to signup, I thought it was useless but there might be a good reason for that?

To answer to that question, the reason why we should redirect to signup when someone uses "Login". User might sign up to a paid service with their first email, then come back to it later and use login with their second email. That will create a second account and one will have to delete it if they care about privacy etc... before signing out and use their first email address to login.

I personally often forget which gmail address I used while signing up with gmail (it is just me ? 😄 ) so it happened to me quite a few times.

[kant01ne]

Moving the discussion to https://www.notion.so/Social-Login-972e603a6a814f209f6f53e4c025a278 before creating separate github issues after architecture decisions are made.

[mufassirkazi]

Testing out Auth0

Q. Can you switch between social login providers? Use Twitter once, then facebook?

• Ends up creating different tenants / accounts

Q. If a user logs in via some provider, and then logs out of that provider on the same machine, should we also log the user out?

• I didn’t get logged out

Q. If a user signs up with social login, then is it possible for them to follow the reset password flow and then sign in with email password?

• No, not possible. You don’t get the email for email password reset. Plus there is no error state, which is bad UX I guess.

Q. If a user signs up with email password, and then sign in with a social login (with the same email), should that be allowed?

• If you sign up with email, then try to use the same email social login provider (sign in with google), you end up creating two different accounts

Testing out Firebase

Q. Can you switch between social login providers? Use Twitter once, then facebook?

• Signed up using twitter. Tried signing in with GitHub, was told you already have an account associated with this email using Twitter. Sign in to Twitter instead? And now if I sign in with twitter and then sign out and now again try to sign in with Github, I am signed into my Twtitter account (the two accounts have been linked)

Q. If a user logs in via some provider, and then logs out of that provider on the same machine, should we also log the user out?

• I didn’t get logged out

Q. If a user signs up with social login, then is it possible for them to follow the reset password flow and then sign in with email password?

• Once you type your email, you are said that you already have an account associated with this email id. And then a CTA with sign in with social provider

Q. If a user signs up with email password, and then sign in with a social login (with the same email), should that be allowed?

• Both accounts get merged as one

[rishabhpoddar]

It seems that a lot of security issues happen when we try and link accounts implicitly during sign up / in. I prefer the approach where we don't allow such linking. There are two cases:

Same email used with different login providers

Scenario: The user signs in first with google with a@example.com and then logs out and signs in with twitter using the same email

Solution: We ask the user if they want to create a new account or instead login with google (or other linked accounts for that email).

Different email used with same login provider (and same browser)

Scenario: The user signs in first with google with a@example.com and then logs out and signs in with google again, but using a different email.

Solution: We ask them if they want to create a new account, or sign in with a previously used google email.

Note: This only works within their already used browser.. if they do this in a new browser, it will simply create a new account.

[rishabhpoddar]

How email verification will work with this

Email verification is not required

• Then the social auth provider need to provide us with an email...
• We still save the is_verified in the database if the email is given by the auth provider (default is false)

Email verification is required

• Then if the social auth provider does not give us an email, then we should not allow its usage (UI needed @mufassirkazi )
• Otherwise if the email is verified, then we treat it as such, else we show the regular email verification flow.

[rishabhpoddar]

In the first version, we will not take care of scenarios mentioned in https://github.com/supertokens/supertokens-core/issues/154#issuecomment-767323453

We will also not add the ability to add custom sign up fields for social login, as that is something that the user can implement as a post sign up screen fairly easily.

[rishabhpoddar]

Closing this issue as we have more or less finalised on the flow

[rishabhpoddar]

@NkxxkN one edge case we did not think of: What if initially email verification is off, and a user signs up with a social provider that does not have email (but they can still use the app). Then, the dev decides to switch on email verification.. this will mean that that user who had signed up is in an error state.. what happens then?

Possible options: 1) We have an error screen specifically for this in the email verification screen asking the user to logout and create a new account with a different social provider or contact support. 2) We do not allow users to sign up in case social provider has no email, regardless of email verificaiton being on or off (i don't like this personally) 3) We ignore this error by:

• showing a generic something went wrong screen in the email verificaiton screen
• Showing the email verification screen as is (but not actually sending an email..). Since this whole flow is an edge case, maybe this might be fine? (If we do this, we should warn devs to not switch on email verification unless they have 0 users or all users in the db have an email).

What's your preference?

[kant01ne]

Option 1/

• Asking to create a new account: Not possible. The user could be using this account for a long time and have data that can not be migrated to a new account.
• Asking to contact support makes more sense. I think that solution is fine.

Option 2/

• Easy solution. I don't mind doing this in the first place and revisit later if we get complaints.

Option 3/

• This option is basically doing nothing? Since this is edge case I guess that is fine. In comparison, option 1 is only having a NO_EMAIL error as a possible response status in the EmailVerification FDI, and showing a different error with more information. Is it worth fixing adding logic for this?

Option 4/ (Ideal, but more work) => on NO_EMAIL response on email verification screen => add an input to create an email. That means new UI and new FDI/CDI.

My preferred option is option 2 as it means we are not handling this edge case from day 1. Forcing people to use third party for which an email is associated which will be true in more than 99% of the cases.

[rishabhpoddar]

Forcing people to use third party for which an email is associated which will be true in more than 99% of the cases.

Can you back this claim up by facts (about it being 99% of the cases). If we can, then I don't mind going for this one.

showing a different error with more information (from option 3).

This is similar to option 1 then... I think we might have to accommodate for this anyway given that it will be its own recipe. So maybe this is the right way to go..

[kant01ne]

Can you back this claim up by facts (about it being 99% of the cases). If we can, then I don't mind going for this one.

No I can't haha. True. It's just a feeling really. I might be wrong. But I'd rather prefer discovering that I'm wrong with customers saying they have a specific use case where they need this feature than discovering that I was right and that we built something buggy assuming I was wrong. In the first case, we will know it's a scenario that is serious enough so that we can think about a proper implementation (something like option 4).

[rishabhpoddar]

But I'd rather prefer discovering that I'm wrong with customers saying they have a specific use case where they need this feature than discovering that I was right and that we built something buggy assuming I was wrong.

Agreed. Have changed the CDI / FDI specs to reflect this.