https://workos.com/blog/a-guide-to-magic-links

Similar to forgot password recovery email.

Basic flow (* marks admin settings for configuration):

  user requests magic link login with username (or email) (* setting both, email, username)
  roundup action receives request and generates:
      url to ?@action=magic_link&key=long_random_string_64+_chars
    session db stores long_random_string_64+_chars as key with value blob:
         username=username
         optionally store random cookie "magic_link"="random nonce" different from
            one in magic link url. Expiration on cookie 2x link timeout
            (* setting enable magic_link cookie)
         timeout= now+10 minutes  (* 10 minutes)

  notification page to user include magic_link cookie nonce. It reports to user that
    magic link was sent to their email address. Remind them to check
    spam folder if they don't see it. Also tell them that magic link should be
    opened in the same browser if magic_link cookie set.

    If username was used to request link, use masking when reporting primary address,
      or use alternate message: "magic link sent to primary email address for username".
      E.G. user@example.com gets masked as as __er@exa____.c__.  (* email address for
      username: none -> alternate message, masked)

    If email address is given to login, don't mask the email address.

    If the email address or username is not found, report the email address or
       some masked username and dummy domain as though it had been found. Basically
       don't let magic link request be used to guess usernames/email addresses.

  when url is triggered code:
         looks up long_random_string_64+_chars
         verifies that current time is < timeout
         if "magic_link" cookie is in use, verifies that request has the cookie set and
            match random string.
      if both verifications pass, log user in and generate session cookie.
      if any verification doesn't pass notify user the magic link is invalid
      if the value reports that the magic link token has been used, notify user
         it has been used and to notify the tracker admin.
 
      Invalidate the data associated with the long_random_string_64+_chars and
        set lifetime to 1 hour so use of consumed magic token is recorded for 1 hour
        to let user know something has gone wrong. (* lifetime setting???)

Additional concerns:

   use ssl based smtp channel to prevent man in the middle (mitigated
      by magic_link cookie that requires url be opened on same browser used to request
      the magic link email/url; also notification that link has been intercepted/used).

Explanation above doesn't handle case where user needs to create account.
This can be handled by instant_registration=email. Code may need to change
to allow creation of new account without password. This case could be handled
by creating a long random password for the account. User can choose to set it
by password recovery or from user detail page.

Without a password, sensitive tasks that require re-authentication (e.g. for primary email
or password change) can't be done. So some thought needs to go into those flows if re-
authentication requirement is added.

For case where username/email address is not found use some method to delay
responding to user. The delay should simulate sending an email. Possibly send
actual email to devnull or other junk address. Otherwise a timing attack
could be used to find valid accounts/addresses as the response time will be longer
if user is found.

Also need some method of rate limiting requests for magic link. Otherwise it is
easy to spam a user. Since usernames can be seen in Roundup, this argues for using
email address (which are not shown by Roundup) to trigger a magic link.

Consider using a time delay as with the registration form to deter bots, or an explicit
rate limit like login. Not sure what is a good delay as typing in just an email address
can be pretty quick.

Maybe reuse setting of login_attempts_min config setting to limit login attempts by
client IP. This requires that the roundup app has access to the client IP
by configuring roundup to allow access to X-Forwarded-Host or using REMOTE_ADDR if
a proxy is not used. Rate limit only on username may not work as finding valid
accounts requires using different usernames/email, but will limit spamming a user.