-
Notifications
You must be signed in to change notification settings - Fork 0
Extending Passwordless Sign In
It is possible to eliminate the use of passwords to sign in and instead send an email with a secret link for the user to click.
But going to your email account and clicking the link is sometimes harder than typing a password, especially if the password is easy to type and not very secure. However there's another way to approach email-based sign-in: automatically pop up a sign-in dialog.
You can do it with a client-side app that detects the sign-in email and posts a notification.
Email-based sign-in works this way:
- In the sign-in screen, the user provides their email address.
- The system emails a link containing a secret token.
- On opening the link the user is signed in.
The new method would extend the typical one:
- In the sign-in screen, the user provides their email address.
- The system emails a link containing a secret token.
- The email has a new header containing the sign-in link.
- Some users have an app which auto-detects messages with the new header. The app pops up a notification without the user leaving the original sign-in screen.
- On opening the link the user is signed in.
- On pressing "OK" in the notification, the user is signed in.
The client-side app must be convenient and reliable.
It must allow the user to have multiple devices, in case the device on which the app is running is not the one the user is currently in front of. It must not hog the notification.
Different platforms will have different pros and cons.
Browser extensions can integrate closely with browser apps. They can pop up a familiar Javascript dialog in-place in the sign-in form. There would be so little friction that the user would hardly be aware of the message bouncing off their email and coming back to the app.
A mobile implementation can use push notifications. If the user is signing in via a smartphone app, the notification can pop up right over the sign-in screen. And mobile apps need this benefit, since it's hard to enter a secure password on an awkward phone keyboard.
A dumbphone can use SMS to get the user's assent. The email listener could run on a cloud server, then send a text message with a sign-in link or token.
Desktop software can bounce an icon in the dock, or use Growl to display the notification unobtrusively.
Anything coming in via email might be spam. The client app needs to have spam filtering. It should check for senders at black listed domains. It should check for red flag words. An automatic sign-in flagged as spam should still be available for the user to seek out, it just shouldn't grab their attention.
Malware distributors might try to trick people into going to their sites. Phishers might play tricks with the identity of the site in the notification. Automatic sign-in apps should use something like Google Safe Browsing.
The contents of the email shouldn't be shown: they're too good a conduit for malware, and a standardized OK/Cancel dialog is better for usability. If there is a certificate for the site that the user is signing in to, the auto-detection app should show the certificate, along with the same kind of icongraphy as a browser (lock, warning sign, etc). If there is no certificate, the app should say that.
If the sign-in email is unwelcome, it may well be malware. Users should be able to flag unwelcome sign-in emails.
The sign-in window used to send the email should not be assumed to belong to the same user who OK'd the sign-in. Users might OK a sign-in without understanding it. If the window used to originate the sign-in request is authenticated when the owner of the email opens the sign-in link, the address' owner could be impersonated by anyone who cared to use their address.
The strength of the idea of passwordless authentication using email (or SMS) is that it is backwards compatible. There's no need for broad adoption of a new protocol before it is useful. This idea for a new protocol allows for progressive enhancement. Users with the best modern software can have an optimized experience, while other users can still use the system.
The email containing the link contains an X-Passwordless header. The content of the header is a link.
The auto-detection client looks up the certificate of the domain of the link. It shows the contents to the user. The auto-detection client shows the domain of the link to the user. It might show the full link.
If the user OKs the sign-in then the link is opened in a new window.
It's inefficient and slow for auto-detection apps to poll. An app could use server-side search, per RFC 3501. The IMAP Idle command may be the key.
This idea was suggested by Brander Lien while we were chatting. I (Lucas Gonze) wrote this paper to work out the details. I started on May 25, 2014 and finished on June 10, 2014.