Changes to the magic links API between 1.48.3 and 1.55.1?
-
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!
-
@elliotdickison So are you using the hosted login pages are trying to create your own login form? If you are trying to create your own login form, you should check out the Using API Directly magic link documentation.
-
@mark-robustelli Correct. I'm aware we're in uncharted territory and can't expect everything to work smoothly across upgrades, but TBH I don't think our solution is quite as bad as it sounds.
The form is a single input that, when a code is entered, triggers the same request that would fire if the user clicked a magic link in an email. Conceptually we are very close to the built-in flow except that we categorically exclude all of the link verifier bugs and cross-browser complications of the built-in flow.
Regarding the passwordless API, unfortunately that would mean we'd lose the FusionAuth SSO session (source) which is a key feature for us.
-
@elliotdickison I didn't want you to think I forgot about you. So is the main issue what happens with an invalid code? Does this mean when you have a valid code, everything works fine?
Does anyone else have any experience with this? I think it may take me a while to duplicate the setup and start playing with it.
