From what am I reading, magic links require users to provide their email and the user will be sent an email with the link to sign-in, and the users can use this link to log into the system.

Can this be called authentication? What we are validating is only the possession factor making the person has access to the email, no where we are confirming the user identity.

  1. How safe it is to validate only the possession factor of authentication. Anyone who knows my email can request sign-in link on my behalf

  2. Can this be used with public emails like gmail, yahoo?

  3. If this is considered a form of authentication, can it be compared to the authorization_code authorization grant in OAuth? Is the unique code in a magic link comparable to the authorization_code in OAuth?

  • am talking the login mechanism used in Wordpress, Hoteltonight
    – bindip
    Commented May 19, 2021 at 14:16
  • 1
  • Regarding the 'only validating the possession factor: in my mind, this is already the case when someone uses password managers. It only validates the possession of an unlocked password vault. How it came into this unlocked state is of no relevance for the 'what/how many factor' question as it can be anything from plain user negligence, password, biometric, hardware token, ...
    – fleitner
    Commented Feb 2, 2023 at 20:16

4 Answers 4


Is a "magic link" a kind of authentication?

Yes, it is.

It authenticates the user; similarly to reciting a password, calculating a TOTP/HOTP, dipping a possessed smartcard, or presenting a fingerprint, "reading an e-mail inbox" (and thus "clicking a link in an e-mail sent to it") is an ability strongly associated to a particular user.

The emphasized text above may seem like a bold assumption, and it is: for this reason, many services (especially ones that handle money from their users) will put verbiage in their ToS that the user explicitly represents this association, to help give the site legal leverage/slack in cases where the user claims "I didn't do that; my roommate / romantic partner / etc. did".

E-mail can also serve as an authorization channel, if already regarded secure enough for use as an authentication channel. For example, an e-mail that includes an attestation like "click here if you're really trying to add a new device / share this folder / change these settings / grant this 3rd-party app access to your account / etc" would be an instance of "magic link"-based authorization.

However, "magic links" (both for authentication and authorization) are increasingly regarded as an unsafe practice because their use normalizes "clicking on links in e-mails" to the end users. If they can do something by clicking on a link in an e-mail, they could just as well do it through the site or program's interface—such as by entering an alphanumeric one-time code—without increasing their long-term exposure to phishing and CSRF attacks. (There are a few arguable exceptions, such as when more complex attestations—such as solving a CAPTCHA or presenting cookies from an existing log-in—are thought to be appropriate to require from the device on the network which is accessing the e-mail, but, broadly speaking, you should reconsider "magic links" per se in favor of pure authentication codes that don't require "clicking" anything.)

How safe it is to validate only the possession factor of authentication. Anyone who knows my email can request sign-in link on my behalf. / Can this be [safely] used with public emails like gmail, yahoo?

If you already treat e-mail as confidential enough to be a single-point-of-failure for drastic account changes like a password reset, it's obviously no less secure to also allow it for less impactful actions like dispensing single authentication tokens.

If you can't assume your users have a secure e-mail account, you're somewhat SOL without meatspace- or legal-process-based identity verification, though properly implemented 2FA options can greatly mitigate this.

If this is considered a form of authentication, can it be compared to the authorization_code authorization grant in OAuth? With the unique code in the magic link compared to the authorization_code?

The comparison is very strong, but (details aside) there is one big structural difference:

  • An OAuth authorization_code is generated by the identity provider (e.g. Google/Microsoft/Apple/Facebook), who gives it to the resource owner (end user), who gives it to the relying party (independent site) as authentication.
  • An SMTP "magic link" is generated by the relying party (independent site), who gives it to the identity provider (mail server), who gives it to the resource owner (end user), who returns it to the relying party as authentication.
  • Thanks! I agree on the point that this cant be oauth auth grant completely. Since the code is not generated by Identity Provider
    – bindip
    Commented May 19, 2021 at 17:01

Do you know those "Login with Facebook" and "Login with Gmail" buttons all around the web? They are almost the same.

When you allow someone to login with their Facebook account, you are validating that the person have access to that Facebook account and in no way confirming his identity. That confirmation is being delegated to Facebook.

A magic link does essentially the same. Opening the link does confirm that the user have access to the email, but the authentication is being delegated to his email provider.

Anyone who knows my email can request sign-in link on my behalf

People that know your email can try to login on your behalf, and they can do exact the same on your email provider. And on any service on the internet. Being able to try to login isn't the same as authenticating themselves, so it makes no difference.

They won't be able to login because they don't have the link, and if you click on the link, you are logging in, not them. So it does not matter.

Can this be used with public emails like Gmail, Yahoo?

They are not public emails. I have a Gmail account and I am pretty sure it isn't public. A public email would be those disposable emails (like Mailinator, for example).

A public email from Mailinator can be read by anyone, so if your service says "The link has been sent to [email protected]", anyone can just get there and grab the token.

But if the token is sent to "[email protected]," only the owner of that email can access the token. And it makes no difference if the email is from Google, Yahoo, or the White House: only the one (or ones) with access to that email can have the token.

If this is considered a form of authentication, can it be compared to the auth_code authorization grant in oauth?

If the token cannot be reused, it's the same as OAuth.

  • as a follow up... in oauth authorization grant.. a auth_code is generated only after the user verifies their identity. But in here, a code will be generated when the user email exists in the system which doesnt confirm the user identity or possession of email. The actual identity/possession is established when the user clicks the link in the email to authenticate. Can it still be considered oauth ?
    – bindip
    Commented May 19, 2021 at 16:00
  • @bindip in OAuth, the grant is generated only after an administrator is authenticated, this is not the same user as the one the grant is sent to. Also, the grant is an authentication token in the sense that anyone who get access to it can authenticate (for ex. if the mailbox is shared among multiple persons, anyone of them can use the token to authenticate).
    – A. Hersean
    Commented May 20, 2021 at 8:17
  1. Every classical authentication system with the functionality "I forgot my password, please send me an e-mail" is equivalent to the one you describe. It is simply authentication by proof of ownership of an e-mail address.

  2. Why not?

  3. The generated link contains an authentication token that can be limited to one use, like the authorization grant of OAuth.

  • Forgot My password - isnt authentication allowing the user to access the system, so ownership check should be good enough. But for login, this flow doesnt confirm the user identity at all, anyone who knows X's email can request a login link and X will receive an email. Wouldnt that be concerning for X ?
    – bindip
    Commented May 19, 2021 at 14:10
  • @bindip no more concerning than people requesting password-reset e-mails, unless you see a reason why? Commented May 19, 2021 at 17:00

A magic link is equivalent to an authorization code in OAuth2. Neither an authorization code nor a magic link explicitly identify who is accessing the resource. This makes it a form of authorization rather than authentication, because anyone who knows the link or token can access the controlled resource. From your link:

Anyone with the login link will be entitled to acces [sic] the corresponding user’s account until the link expires.

Authentication in OAuth2 comes from steps in the flow before the authorization token is issued. Similarly, the authentication in issuing a magic link comes from sending the link to a specific email address, presumably after taking steps to ensure that the email address is controlled by a specific principal and that the principal will not share the link with any other principal. Any weakness in email privacy would map to a weakness in the integrity of authentication.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .