Earlier quoted context omitted.
> I don't want to impose that privacy failure on my users, but I also don't want to impose the annoyance that is "Sign up with a username, email address, and password". Why not just 'log in with email address'? The user provides his email address; you send him an email with a URL of the form http://www.invalid/path/to/resource?access_token=aSBkb25lIGF... (where aSBkb25lIGF1dGhlbnRpY2F0ZWQgdGhpcw is a cryptographicall…
This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons. Youre putting the responsibility of security on the email provider, which you can't control.
No, it's essentially the same thing as having a password-reset email sent to one, which is already the case for just about any account anyway.
> You're putting the responsibility of security on the email provider, which you can't control.
Your email provider is already capable of visiting a site, claiming to be you & claiming to have forgotten your password, then intercepting the password-reset email and resetting your password (about the only sites which require more than this are banks).
You can extend any flow which is secure against an evil email provider resetting a password to be equally secure against an evil email provider logging in. Obviously you could add an SMS code, which would then require subverting your mobile provider as well as your email; ditto a landline call.