Revoke embedded magic links

Questions
1

Is there a way to revoke an embedded magic link?

The problem we’re facing is with this scenario:

A user tries to login with nikc@gmail.com so we create an embedded magic link and send it there. They had a typo in their email and try again with nick@gmail.com. Now when we get the token after the user clicks the link we have no way of knowing which email is the one that was authorized (as far as I know).

Ideally, we could only have one active magic link per user, or at least a way to revoke the first token we sent before sending the second one. We could store the latest token and ignore any other tokens that come in for the user, but that feels awkward and it would be great if that was supported on the Stytch side.

I see there’s a way to revoke a non-embedded magic link with the /magic_links/email/revoke_invite endpoint, it would be great to have the same for embedded links.

Thanks,
Nick

2

Hey Nick – thanks for posting!

Just to make sure I understand correctly before suggesting a solution, were two separate Stytch Users created for those two email addresses? Our Embeddable Magic Link endpoint accepts a user_id (rather than an email address), so I’m wondering if your application first creates the User via the Create User endpoint and then passes the resulting user_id into the Create Embeddable Magic Link endpoint, or something along those lines.

If two separate Users were created in this case, then I think there are some fairly straightforward solutions – but just want to double check first that that’s what happened. Thanks in advance for the additional info!

3

No only one user gets created :+1: The main problem is we need to know which email was validated. With the normal non-embedded flow this is easy because it’s on the Stytch user object. With the embedded flow it doesn’t get added to the Stytch user.

4

I know you guys aren’t in the email flow with embedded links so it’s impossible for you to tell us. But we can know if we can just always revoke/expire all but the latest token sent to a user, but as far as I can tell you don’t support that currently, do you?

5

Ah, I see, thanks for the additional info!

We don’t currently have functionality to revoke certain Embeddable Magic Link tokens, but there are a couple workarounds I can think of.

First, if you happen to store the Embeddable Magic Link tokens on your end for any period of time, you could pass the token that you’d like to revoke into our Authenticate Magic Link endpoint. Because tokens can only be used once, this would prevent it from being used by the owner of the incorrect email address.

If you do not store Embeddable Magic Link tokens, then another strategy would be to create one Stytch User per user email address. That way, you could simply delete the User associated with the incorrect email address, which in turn would prevent any Embeddable Magic Link tokens created for it from being authenticated successfully. So, for example:

  1. A user signs up with nikc@gmail.com. You call our Create user endpoint with that email address, and then send an Embeddable Magic Link using the resulting user_id.
  2. The user indicates that they provided an incorrect email address.
  3. You call our Delete user endpoint to delete the previously-created user, which in turn prevents the Embeddable Magic Link token created above from being successfully authenticated.
  4. You then call our Create user endpoint with the correct email address and send an Embeddable Magic Link using the new user_id.

That way, you could also check which email address a given Embeddable Magic Link token is associated with by looking at the user.emails array in the Authenticate Magic Link token response.

Do either of those strategies sound like they could work in the context of your application?