> the flow the magic link is part of is one you initiate
There's nothing stopping anyone else from initiating the flow assuming the common implementation where only an email is required to initiate sending the link.
Here is the link you requested from ‘Android Device’ in ‘Belarus’ - click here to sign in and allow that device to access your account - only click this if you requested this email
You don’t click the link if you didn’t request it.
The phisher will be on the phone with their victim, pretending to be a support agent for the business. They will say, "Yes click the link, that's how you verify with us."
So many people on this thread leaping in with the phishing threat model.
This is a simple quick login process, you wouldn’t use it in a place where 2FA is required. It is a mistake to think of this as a substitute for 2FA just because it has some of the same elements as a secondary device authentication. It’s not intended to be a 2 FA flow though! It’s a single factor - ‘does the user have access to a device that can read emails sent to this associated email address’. We aren’t combining it with a password or anything else.
That is the same level of auth used for things on many services like ‘registering for a free account’, and frequently for ‘resetting the password on an account’.
It’s not a complete security solution and you wouldn’t use it everywhere. It would be a bad fit for a banking app or access to a publishing interface. It’s not a bad interface for things like ‘logging in to my subscription on the TV’ or ‘returning as a customer to a website I shopped with once before’.
There's nothing stopping anyone else from initiating the flow assuming the common implementation where only an email is required to initiate sending the link.