We are implementing Stytch into both our webapp and iOS app for b2b using discovery. How do we handle the case where a client needs to auth into our iOS app but does not have their email logged into the device? Can we use OTP to do the discovery flow?
Hey Tyler,
Thanks for posting!
For context, our Discovery flow currently only supports Email Magic Links and OAuth as authentication factors, and does not support other factors like Passwords.
Our reasoning behind this decision is that we consider other login methods (like Passwords) to be a weaker verification of the user’s identity/ ownership of the email address (compared to Email Magic Links or OAuth), and prefer to avoid using it cross-Organization.
Can we use OTP to do the discovery flow?
To confirm, are you referring to SMS OTP here?
If so - in our B2B API, SMS OTP is only available as a form of MFA; not as a primary authentication factor. This is for similar reasons to the above - in B2B, we found that most use cases required strong guarantees around email ownership and verification. Email domain is what Organization authentication settings key on, so we require an authentication flow that verifies email ownership during in the Discovery flow in order to find relevant Organizations that the user is eligible to join or log into.
How do we handle the case where a client needs to auth into our iOS app but does not have their email logged into the device?
For our own understanding, is this a scenario you expect to arise often with your use case? If so, are you able to provide a bit more context on the use case, so we can help to think through any potential alternative solutions?
So is the only way for our customers to auth into our app being through magic links from an email client on the device? It’s difficult for us to commit if magic link is the only way to auth into our mobile app as it’s the core product our customers use. We primarily sell B2E and what it sounds like, if the customer does not have email clients on the iOS devices, there will be no way for them to auth into our app?
Our app powers field data collection for B2E companies. Depending on their policies they may not allow email clients to be logged into these field devices. Thus, we would need to provide another way for them to auth in that is not only magic link. Is there another solution?
Also, how do we get a magic link only approach through app review? They require login.
Got it - thanks for the additional context!
So is the only way for our customers to auth into our app being through magic links from an email client on the device?
For the Discovery flow in our B2B API specifically, the two supported authentication flows are Email Magic Links and OAuth (e.g. sign in with Google or Microsoft), because these two methods strongly prove ownership of the email address in question.
Also, how do we get a magic link only approach through app review? They require login.
We’ve found that typically app reviewers are comfortable using their own email address for login flows - many applications use passwordless, email-based authentication methods! If for some reason this does present an issue, one option would be to setup a temporary shared email domain or something similar for the app reviewer.
Our app powers field data collection for B2E companies. Depending on their policies they may not allow email clients to be logged into these field devices. Thus, we would need to provide another way for them to auth in that is not only magic link. Is there another solution?
A few follow up questions to help us better think through this:
- What are your application’s (primary) authentication factor requirements?
- You mentioned SMS OTP - is this a strict requirement, or are you looking for any non-email based authentication method (e.g. where something like Passwords could work)?
- Is the Discovery flow (rather than an Organization login flow) a strict requirement here?
- The limitations on authentication factors mentioned above only apply to our Discovery flow, since this flow involves finding Organizations that someone is eligible to join (or a member of) based on their email address. The notable difference is that Organization login flows support Passwords.
- Can you talk through your multi-tenancy data model with this B2E solution a in a bit more detail?
- For some additional context, we designed our B2B solution around email address verification because we found that typically, B2B or B2E applications rely on validating the end user’s association with an Organization (e.g. a tenant/company), and that email address verification is the most secure way to do so (whereas phone numbers, for example, are less strictly mapped to a particular Organization or company).
Thank you for the detailed response.
We could look at the organizational flow, this may work.
With the discovery flow, why only support magic link? Why not support OTP code in an email, rather than a link? This way you put the email into the app, you get the email (likely to desktop) with the OTP code that you type into the mobile app which then gets your the org lists? This flow would allow us to not worry about customers having an email client on their phone.
This is the flow that Slack uses, and it’s really clean.
We could look at the organizational flow, this may work.
Awesome - let us know if any other questions come up while you look into this option! The main difference is that login will need to happen on a page dedicated to a specific Organization - for instance organizationA.myapp.com/login rather than myapp.com/login.
Why not support OTP code in an email, rather than a link?
Email OTP support in our B2B is something our team is actively working on!
It sounds like this could be a potential workaround as well (I didn’t realize end users might have access to email on a different device!) - what’s your timeline for implementation? Let me check in with our Product team on the timeline here in the meantime.