RFC for Magic sign-in link via email

[adanielyan]

Summary

Add a "Magic sign-in link" option to the available authentication methods. Users must be able to choose a Magic sign-in option in addition to any other enabled option to sign in. This authentication method should work for both the Directus app and authentication through API. This authentication should be an extension of default (database) authentication. That is, the auth method on the account will be "default". As a result only accounts with a "default" authentication method will be able to use Magic link auth, although it may change in the future when/if authentication by any method (regardless of what method was used to create an account) is supported by Directus.

Basic Example

Example 1

1. User opens the Directus app, enters email and clicks on "Send me a magic link" link/button
2. Directus generates a magic link and emails it to the user.
3. User clicks on the link in the email that authenticates them and redirects back to Directus.

Example 2

1. User opens a custom app that has uses Directus user authentication under the hood.
2. User enters email and clicks on "Send me a magic link" link/button.
3. Directus generates a magic link and emails it to the user.
4. User clicks on the link in the email that authenticates them and redirects back to Directus.

Motivation

Magic link authentication is becoming increasingly popular and are considered a safe way to authenticate user without password. It would be good to support this authentication method.

Detailed Design

Use case 1

1. User opens the directus app
2. If Magic link auth method is enabled, user sees a "Send me a magic link" link/button under the Email field

3. User enters email and clicks on Send me a magic link button.
4. If a user with a given email exists, Directus automatically authenticates that user and generates a refresh token.
5. If user doesn't exist, Directus creates one and generates a refresh token, similar to OAuth authentication.
6. A URL containing a Directus token refresh API endpoint URL, the redirect URL (that is the Directus instance URL), and a refresh token is generated.
7. That URL is then emailed to the email address provided by the user.
8. A message appears confirming that the email was sent.
9. User clicks on the link in the email that takes them to the token refresh API endpoint (see the drawbacks section below).
10. If token is valid the token refresh API does its job and redirects user back to a redirect URL with a cookie that has a new access and refresh tokens (similar to regular API token refresh).

Use case 2

1. User opens a custom app that has uses Directus user authentication.
2. If Magic link auth method is enabled and added to the app's login form, user sees an email field and "Send me a magic link" link/button. The UX implementation will be up to the app's owner
3. A request with user email and the current page URL is sent to a new Directus API endpoint.
   Steps 4-10 are same as in Use case 1, but the redirect URL in step 6 will be the app's page URL submitted to the Magic Link generation API endpoint.

Requirements List

Must Have:

• Token refresh API endpoint that accepts GET requests

Should Have:

• To support magic link generation through API a Magic link generation API endpoint should be created

Could Have:

• ?

Won't Have:

• ?

Drawbacks

To implement this approach the token refresh API endpoint will have to accept GET requests, as you cannot send a POST request from an email. While this may sound as a security risk, in reality it is not, as the refresh tokens can only be used once, and are discarded after a new refresh token is generated. But there may be other negative consequences that I cannot think of at the moment.

Alternatives

Using 3rd party OAuth providers, such as Auth0 to enable Magic link authentication.

Adoption Strategy

TBD

Unresolved Questions

No response

[akiarostami]

For passwordless entry, I would also love to have the OTP option, so instead of a link, the user would get a 6 (or more) digit number to log in.

[rijkvanzanten]

You mean that the OTP is sent as an email still, or do you mean like two-factor authentication where the user enters their login information (email/password) and then an OTP for added security?

[akiarostami]

I mean OTP sent to an email for passwordless entry, and not TFA. Just like a magic link (instead of a link) a number is emailed to the user. With that, there would be no need to sign in via URI, and there would be no redirecting the user after auth. User stays in the log-in form with a field to enter the OTP number and login. Later on this can be extended to receiving a text message with that 6-digit number instead of email.

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[w0kyj]

Related Feature Requests:

• Implementation of Passkeys Authentication in Directus for Enhanced Security #18755
• Passwordless signin : FIDO2 #13163

[rijkvanzanten]

Thanks @adanielyan! The front-end steps make a ton of sense. I think the last piece of the puzzle for this feature to be a success is figuring out the exact API spec. Couple of questions on that:

• How do you request this link to be sent?
• How do we control where the login link redirects you to (so you can magic-link back to your own app)
  • How do you configure what URLs are allowed (probably same as SSO?)
• How do we unset/expire the token after the login has happened?
  • Quick thought: potentially using a temporary session in directus_sessions just for the login

[vanling]

Simplified From frontend app/development POV using SSO:

On frontend -> trigger "email login"
-> trigger something as -> GET /auth/login/:provider with redirect param (that would be whitelisted (like forgot password))

-> Directus sends the email + link (Directus saves the redirect state on the user on the temp token?)
-> user clicks the link in the email
-> link goes to Directus and login request gets handled and redirects back to app

☝️ this + a poopyload of more details 😛

[w0kyj]

Must have:

• support for custom apps (allow custom implementations to use as auth)