We fully support e-mail based logins, but OAuth can be challenging.
Github OAuth for example will issue a 2FA email-based challenge non-deterministically. We handle that by detecting the challenge and filling out the challenge code based on the contents of the email sent by Github. This requires a one-time setup where you add an email address we control to your Github user so that we can read and parse it.
For Google OAuth we can execute all the steps but the two issues there are (1) we run everything in a single window and some web apps don't like that because they assume the oauth flow will happen in a new window, and (2) sometimes Google prompts you to answer a security question and we don't yet support marking test steps as optional.
What our customers have been doing instead is setting up a mechanism to auto-log in the test user using a magic link. Basically sending in a one-time-use auth code to a URL in their app that then authenticate the user. I think some platforms (Firebase?) have built-in support for this.
I'm certainly happy to brainstorm what could work best for you though if you'd like (my email: todd at reflect.run)
We have the ability to handle MFA logins that use email as the second factor. The way it works is you configure your user account to have an email address that we control (e.g. [email protected]). When the multi-factor challenge comes in, we receive the email, parse it for the challenge code, and fill it in live in your test. We don't have SMS support at the moment but we could take a similar approach there if SMS is used as a second factor. There's a one-time setup here where we set up our system to parse your challenge email.
No support for TOTP unfortunately, but if the SMS or email-based challenge support would work for you feel free to reach out and I can talk to the specifics of the one-time setup - todd at reflect dot run
I would suggest adding the ability to auth via a magic-link in your web app. This would allow your tests to bypass the auth flow entirely by passing an auth token as a request parameter in the first URL of your test. You can pass new auth tokens when you go to run your tests either via the UI or via our API if you have it hooked up to your CI/CD pipeline. More docs on how to do it via the API is here - we call these 'request overrides' in our docs: https://reflect.run/docs/developer-api/documentation/#run-te....
In terms of added security, some options there would be to only enable these "magic links" in staging and only enable this type of auth for a least-privledged user account (e.g. no admin or employee accounts could auth this way).
Magic links sound like they have several pitfalls (the potential for security incidents like Twitter are beeping here) and require significant changes on our end to use this platform
You're right, there's certainly security implications for magic links. Unfortunately for an auth that incorporates hardware keys, I can't think of how you would test behind that without some sort of workaround, but I may be overlooking something.
I generally have service accounts specific for testing with significant restrictions. Hardware keys present their own complications for non-human ops, so they don't really belong there.
More just seeking bounds of possibilities, thanks for your replies.
Github OAuth for example will issue a 2FA email-based challenge non-deterministically. We handle that by detecting the challenge and filling out the challenge code based on the contents of the email sent by Github. This requires a one-time setup where you add an email address we control to your Github user so that we can read and parse it.
For Google OAuth we can execute all the steps but the two issues there are (1) we run everything in a single window and some web apps don't like that because they assume the oauth flow will happen in a new window, and (2) sometimes Google prompts you to answer a security question and we don't yet support marking test steps as optional.
What our customers have been doing instead is setting up a mechanism to auto-log in the test user using a magic link. Basically sending in a one-time-use auth code to a URL in their app that then authenticate the user. I think some platforms (Firebase?) have built-in support for this.
I'm certainly happy to brainstorm what could work best for you though if you'd like (my email: todd at reflect.run)