Hi,
I’m currently integrating Stytch B2B using the Python SDK. For now, I want to continue using sessions.migrate_async so that I don’t have to change my existing login flow too much. I already have an endpoint that validates the user, and the migration itself is working fine.
The challenge I’m facing is related to MFA. I’d like to be able to determine whether an user requires MFA after the migration, so that I can return the appropriate steps, either for MFA enrollment or MFA authentication. I’m already using the Stytch MFA logic for that.
Currently, after calling migrate_async, I attempt to use exchange_async to get the MFA-related fields and the intermediate session token. However, the response returns almost all fields as None or empty:
- mfa_required: None
- primary_required: None
- intermediate_session_token: empty
- member_authenticated: false
Is there a way to integrate MFA for user directly after migrate_async without performing a full login, so that I can handle MFA flows without impacting the main login logic?
Essentially, I’m looking for a way to:
- Detect whether MFA is required for the user after migration
- Access the intermediate session token to continue the MFA flow
- Do this without fully changing the current backend login flow
Any guidance or recommended approach would be greatly appreciated.
Thanks in advance!
Hey @Laura_Saraiva ,
How are you currently creating these Members in Stytch before migrating the sessions? Typically for MFA, you would want to either pass in a mfa_phone_number and mfa_enrolled when creating the Member (more on these params here), and for TOTP devices, migrate them using this endpoint.
The migrate session endpoint also mints a full-fledged Stytch session, and I don’t believe it should ever return an intermediate session or IST (intermediate session token).
Just to take a step back there, do you mind sharing a bit more about your use case and desired behavior here? Are you trying to migrate sessions for your existing userbase so they don’t have to re-authenticate? Or, are you wanting to keep your existing auth/login flow and only use Stytch for MFA for example?
Hi,
Or, are you wanting to keep your existing auth/login flow and only use Stytch for MFA for example?
Yes, exactly.
What I’m trying to do right now is start by integrating MFA only. The migration flow fits well for us because it allows us to validate users without having to refactor the entire login system.
However, I’m currently blocked because the sessions.migrate_async response in the Python B2B SDK does not return the MFA-related fields I need (mfa_required, intermediate_session_token) in order to continue the MFA flow and validate the user.
I also tried calling sessions.exchange_async after migrate_async as a workaround, but that doesn’t work either, the MFA fields are still missing and the intermediate session token is not returned.
Because of this, I’m not able to complete MFA enrollment or authentication using Stytch without changing our existing login flow.
For now I’m currently creating the members manually
That makes sense, thanks for sharing that context!
Currently, the migrate session API is always meant to return a full-fledged Stytch session, and not an intermediate one.
Typically, we’ll see folks continue to use their existing systems for MFA (if any) before calling /sessions/migrate, i.e. handling the MFA logic outside of the Stytch ecosystem.
Alternatively, if you don’t have an existing MFA solution in place, you may have to handle the logic for whether MFA is required in your existing auth code, and primarily use the send and auth SMS OTP and TOTP endpoints in Stytch and verifying you get a 200, throwing away the Stytch session, etc. that’s returned.
I don’t have MFA set up yet, which is why I initially tried using sessions/migrate. I’m now trying to better understand how Stytch’s TOTP endpoints are intended to be used.
Specifically, is it possible to use the TOTP endpoints without an token, or is the token always required?
I’ve already implemented the enrollment and authentication endpoints:
- Enrollment:
totps.create_async
- Authentication:
totps.authenticate_async
For enrollment, I’m passing the organization ID and member ID, and this works fine without providing an token.
However, during authentication, I’m passing the organization ID, member ID, and the TOTP code (without an token), and I receive the following error:
StytchError {status_code=400 request_id='request-id-live-71149020-e88e-4f8f-98f4-ecad76de9631' error_type='no_session_arguments' error_message="Please ensure you're passing exactly one session field." error_url='https://stytch.com/docs/api/errors/400#no_session_arguments' original_json={'status_code': 400, 'request_id': 'request-id-live-71149020-e88e-4f8f-98f4-ecad76de9631', 'error_type': 'no_session_arguments', 'error_message': "Please ensure you're passing exactly one session field.", 'error_url': 'https://stytch.com/docs/api/errors/400#no_session_arguments'}}
Given that I don’t have access to either an intermediate token or an active session at this point, I’m unclear on how these endpoints are meant to be used in this scenario.
Am I misunderstanding the expected flow, or missing a required step? I’d really appreciate some guidance on the correct approach.
Thanks in advance for your help.
Thanks for your reply!
All of the B2B APIs require a session token when authenticating an MFA factor (either a session_token, session_jwt, or intermediate_session_token):
These typically are meant to be called with a session token returned from a primary auth method like email magic links, so it’s not possible to use these B2B APIs solely for MFA in this way (in context of this use case at least).
In terms of using Stytch as an intermediary standalone MFA, you could technically use our Consumer auth to achieve this, keeping the rest of your user states (i.e. whether MFA is required or not) and org login requirement logic in your existing auth systems. e.g. if MFA is required, call create TOTP to register a device then authenticate whenever a TOTP code is entered, the latter of which does not require a session token, then ignoring the Stytch session returned and proceeding in your existing auth system.
Ultimately, if you’re trying to implement a simple stopgap MFA solution and not looking to migrate off your existing auth system eventually, you may find it easier to use something like Twilio Verify instead.
Thank you very much for the explanation. I’ll review it carefully and make the necessary changes.