Is a "magic link" a kind of authentication?

Question

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?

Answer 1

Is a "magic link" a kind of authentication?

Yes, it is.

It authenticates the user; similarly to recalling a password, dipping a possessed smartcard, or presenting a fingerprint, "reading an e-mail inbox" is an ability generally associated with a particular subject.

(It can also serve as an authorization channel. If the e-mail is already being considered authentication, then attestations could also be included in the e-mail text and deemed valid — think e-mails that include statements such as "click here if you're really trying to add a new device / share this folder / grant this 3rd-party app access to your account / etc" — though this is, obviously, far less common than the mere authentication case of "click here to log in / reset your password".)

---

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

If you trust e-mail for a password reset, it's reasonable to trust it for wholesale log-in tokening.

Some services use it as a second authentication factor when logging in from a new location; some that only require 1 factor allow it to be used as such. It's assumed that one's e-mail account will be generally guarded as trusted. (When it isn't considered to be so, forgotten passwords are be much more troublesome.)

(It would probably be wise to make each link one-time, or otherwise expire in a brief <24h window, however.)

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

It can be used with any e-mail provider you already allow as a trusted contact address for your account (e.g. as a forgotten-password authentication method.)

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?

It's nearly correct, but not quite:

• An authorization_code token is generated by the identity provider (then given to the relying party by the end-user/resource owner)
• The magic link is given to the identity provider after being generated by the relying party (and then, from there, given to the end-user/resource-owner to present back to the relying party as authentication)

Answer 2

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 supersecret@mailinator.com", anyone can just get there and grab the token.

But if the token is sent to "supersecret@gmail.com," 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.

Answer 3

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.

Answer 4

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.