yep, we plan to use that for session management

would like some advice though, I see in the database right now that the users with email/password are separated from third party users

ok. So then you can

disableDefaultImplementation

for all APIs provided by thirdpartyemailpassword by putting that boolean to true in all feature objects (https://supertokens.io/docs/nodejs/thirdpartyemailpassword/init)

> would like some advice though, I see in the database right now that the users with email/password are separated from third party users Correct.

let's say my app can connect multiple social logins under the same "user", this isn't a concern of supertokens right? so I'll need to have my own "users" table of some sort to achieve what I need (on top of the extra fields)?

at least that's the impression I get just from looking at the tables 🤔

So you mean creating your own table to use along with the tables we provide? Or not use our tables at all?

the former

yea. You can do that.

how would you recommend the schema to look like?

But I would advice to not link accounts implicitly since it can result in security issues. For example, if you provide fb and google login, and the user has the same email ID. If they use google to sign up, and their FB account is compromised, then the attacker can sign in to your service with their FB account and gain access to that user's account as well.

when we were managing our own, it was just userId // managed by our app oidFacebook // openid value oidGoogle // openid value oidGitHub // openid value

that way, we can map it to the same "user" even w/ multiple social logins

You should map your userId to the userId provided by these social login providers.

as opposed to the openid token

yes, that but in the case of supertokens, my users table would then reference to the `user_id`s on the

thirdparty_users

right?

users table schema

ts
userId // managed by our app
stFacebook // userId in thirdparty_users where third_party_id is "facebook"
stGoogle // and so on...
... // extra fields

or is the

user_id

from supertokens a different thing?

or... is it unnecessary and I could just reference directly instead to the

third_party_user_id

?

> but in the case of supertokens, my users table would then reference to the user_ids on the thirdparty_users right? Yes. Exactly.

You should try and use the same userId we have in

thirdparty_users

table throughout your app

So:

userId // userId in thirdparty_users table
stFacebook // third_party_user_id in thirdparty_users where third_party_id is "facebook"
stGoogle // and so on...
... // extra fields

But of course, you don't need to do that.. you can use your own userId as well...

wait, there's a way to set the userId on supertokens' tables? 🤔

But if you use your own userId, then functions for user paginations will return our userIds, and you would have to remember to fetch your userIds when paginating...

> wait, there's a way to set the userId on supertokens' tables? There isn't.

then this shouldn't be possible right? because for every unique social login, a new

user_id

is created that's why the

user_id

in our custom "users" table is managed by our app. unless I misunderstood

ah yea.. that's true. My bad.. hehhe

np 👌

so you would have to create your own userIds.. yea and map those to our userIds, and then remember to fetch your userIds whenever dealing with our userIds.