4

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?

2
5

Is a "magic link" a kind of authentication?

Yes, it is.

It authenticates the user, similarly to having them type a password, dip a smartcard and enter its PIN, or checking their fingerprint. It is not (inherently) authorization, since "clicking a link on an e-mail" doesn't necessarily attest 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

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)
1
  • Thanks! I agree on the point that this cant be oauth auth grant completely. Since the code is not generated by Identity Provider – bindip May 19 at 17:01
4

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.

2
  • 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 May 19 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 May 20 at 8:17
1
  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.

2
  • 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 May 19 at 14:10
  • @bindip no more concerning than people requesting password-reset e-mails, unless you see a reason why? – JamesTheAwesomeDude May 19 at 17:00
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.