Hey guys, Do I get it right regarding user IDs in supertokens recipes -- each recipe maintains it's own set of users when using MFA?

Yea correct.

We had Passwordless recipe with phone_number+OTP in our app. Now we want to switch to phone_number+password as the first factor and OTP as the second factor (used https://supertokens.com/docs/phonepassword/introduction as reference) So this means that if the session was created during EmailPassword recipe (where we have phone number instead of email), then the user ID when calling

session.get_user_id

is going to be different than it was with Passwordless recipe 🤔

yea, but the final session of the user can still be changed to using the user ID from the passwordless recipe. In the phonepassword guide, we basically do not create a new session in the second factor step and continue to use the first session. But you can not do that and create a new session which would match the user IDs of the current user.

right! the easiest way would be to create a new session there thanks @rp_st 😄

yup. Which is does by default anyway. The guide above actually makes it not do that to maintain the session user ID from the first factor

btw, creating another session when 2FA is fully completed makes it even more secure -- we include user roles in access token payload only when both factors a completed 😄 this way the potential attacker won't know the privileges of a user even if he can guess the password

Makes sense!

Hey @rp_st , I've discovered an interesting behavior - the client gets "unauthorized" message when querying

/signinup/code/consume

with a correct OTP (second factor auth where a user must verify his/her phone number). This happens due to the revocation of the old session created in

emailpassword

recipe:

python
async def create_new_session(...):
  ...
  old_session: SessionContainer = user_context.get("old_session")
  if old_session and isinstance(old_session, SessionContainer):  # second factor OTP login
    ...
    await old_session.revoke_session(user_context)  # BUG?
  
  return await original_implementation_create_new_session(...)

Is this an intended behavior?

you should not revoke the old session, instead, when you create the new session in second factor, it will simply overwrite the cookies of the older one.

got it 😄 thank you! it's just that I got used to cleaning up everything 😁

fair enough!