showUI option for loginWithSMS for custom PIN form UI

[disbelief]

✅ Prerequisites

• [x] Did you perform a cursory search of open issues? Is this feature already requested elsewhere?
• [x] Are you reporting to the correct repository (magic-sdk)?

✨ Feature Request

Allow sites to display their own UI for the SMS verification form instead of using the branded Magic form. This would be similar to the showUI: false option of loginWithMagicLink, but would also require a new API method to pass the user's verification code to Magic and receive the DID.

🧩 Context

Currently the only way to fully customize the UI is to use Magic link authentication flow. However for business reasons my app must use SMS verification codes for authentication. It would be ideal to fully customize that form and remove Magic branding in order to keep the look and feel consistent with the rest of my app.

💻 Examples

Flow would be something like below, though perhaps a new function would be desirable instead of changing the return type of loginWithSMS.

try {
  await magic.auth.loginWithSMS({ phoneNumber, showUI: false }); // returns void if showUI === false
} catch {
  // Handle errors if required!
}

// ... render custom verification code form

function onVerificationCodeSubmit(code: string): void {
  try {
    const did = await magic.auth.verifyCode(code);
  } catch {
    // Handle errors if required!
  }
}

[smithki]

We are aware of this feature request and it's in our backlog, but we're waiting for more concrete validation before we start scoping anything out. There are a few caveats that make executing on this request non-trivial, such as:

1. Finding an API that works generically for most use-cases while retaining Magic's distinctive simplicity.
2. Identifying the interplay between a custom pin-code form and our integrated MFA flow. Finding a way to support these flows together with a custom UI, without limiting Magic's ability to iterate quickly on UX, and with minimal developer impact (i.e.: no breaking changes) is hard stuff!
3. We must verify this feature request is portable across platforms (at least web & React Native, together).
4. Internally, we would need to discuss the impact a reduced brand presence would have on our business.

I'm responding here to be as transparent as possible about our decision-making process and how we prioritize feature developments impacting our core platform. I don't want to provide an absolute answer as to whether we can ship this request for you, but I don't expect it would happen sooner that Q3-4 of 2022 (possibly later). If your business case necessitates special considerations, I encourage you and your team to reach out to our sales folks so we can work out a plan to support your specific requirements.

Leaving this open until a more definite answer can be provided 🙂

[disbelief]

Thank you for the response, I appreciate the transparency.

I see you've tagged this as "needs more info" so I wanted to offer to answer any questions you may have as your team validates this feature request.

With respect to the points you've raised:

1. Finding an API that works generically for most use-cases while retaining Magic's distinctive simplicity.

Your current API seems like a "good for most" solution already, so I'd recommend creating a separate API for this rather than changing/complicating the existing loginWithSMS functionality.

2. Identifying the interplay between a custom pin-code form and our integrated MFA flow. Finding a way to support these flows together with a custom UI, without limiting Magic's ability to iterate quickly on UX, and with minimal developer impact (i.e.: no breaking changes) is hard stuff!

One possibility could be something akin to what Stripe does with its Stripe Elements component system. It allows users to provide design for the components but the interactions and functionality are still driven by Stripe.

An alternative would be more options in the Branding section of the Magic dashboard interface, permitting removal of the brand if desired (could be an upsell/paid feature).

3. We must verify this feature request is portable across platforms (at least web & React Native, together).

Don't see how this would be a problem, aside from added time spent implementing the support across all platforms.

4. Internally, we would need to discuss the impact a reduced brand presence would have on our business.

Considering that you already have the showUI and redirectUri options on your most popular login method (loginWithMagicLink), it seems a decision has already been reached on this. The fastest, least technical, and "good enough" approach will always be using the hosted UI regardless of these more advanced options.

[am-hernandez]

Hello @disbelief , sorry for the delay in response and thank you for this valuable feature request. I have shared your request with the team so that we may discuss it and possibly add our roadmap.