Hi all,
We're currently on 1.48.3 and are attempting to upgrade to 1.55.1. The only sticking point for us seems to be a change to the magic links API.
Background
We use FusionAuth's built-in magic links flow with two exceptions:
- We have a custom passwordless email template that includes the code in large text for the user to read/copy instead of embedded in a link for them to click.
- We've updated the OAuth2 passwordless theme file to render a form where the user can enter the code manually. The form is shown after the user requests a passwordless email (in place of the "check your email" message rendered by default).
When a user enters a code in the form we send a POST request to /oauth2/passwordless containing a "code" field set to the code, a "postMethod" field set to "true", and all the standard oauth fields via the "@oauthHiddenFields" helper.
This worked perfectly in 1.48.3. A valid code would authenticate the user and redirect them back to our app. An invalid code would re-render the page with an error message.
This provides users with a nice Slack-like OTP auth flow and sidesteps all the issues with one-time links taking users to the wrong browser or getting invalided by link verifiers.
The problem
This flow doesn't work in 1.55.1. Specifically our custom form that POSTs the code to /oauth2/passwordless results in the page just reloading without authenticating the user.
In an attempt to fix the problem I updated the custom form to redirect the user to /oauth2/passwordless/<code> per this post. That does actually fix the sign in flow if the code is valid! However if the code is invalid then the user is redirected to the new confirmation page meant to protect against email client link verifiers*. When the user clicks the "Confirm" button they are redirected back to the app without an error message (and obviously without being signed in as the code was invalid).
*My guess is that this feature is the reason that the behavior of the /oauth2/passwordless endpoint changed.
We could potentially "fix" the invalid code flow by updating the theme file for the new confirmation page to redirect the user back to the passwordless page, probably with a query param indicating that an error message should be shown. Because we use manual code entry instead of links the user is forced to complete sign in where they started. The confirmation page should never be shown in this case, so updating it to redirect should be safe. This feels like a hack that we'll regret though.
The question
What changed with the /oauth2/passwordless API, and what is the best way to continue supporting Slack-like OTP sign in codes (without hacking our FusionAuth theme to bits if possible)?
Thanks!