I like Ben Browns take on password-less logins which motivated me to explore his direction further: Could we skip usernames and all the other steps too? My idea lends heavily on his work, OAuth (and others I’m sure.)
You visit a site on your computer and point your camera phone at the barcode next to the login form. Page reloads instantly and you are logged into your account.
Next site; you scan the barcode but you’re not registered. Phone asks if you would like to. At the split second you confirm; page reloads into your new account.
Let’s turn to the server to learn how it works:
I’m the server, and I generate a unique auth-code for everyone loading the site. This code contains a randomly generated but unique number as well as the address to my public key and to my auth-gateway.
The visitor may use her auth-client, in this case an app on her phone to scan the auth-code, and it immediately opens a connection to my auth-gateway to authenticate.
If my auth-gateway happens to get a message containing the unique number; I know the person with that number wants to log in.
All messages to the auth-gateway are encrypted using my public key and signed with the visitor’s private key. So I verify her identity using the public key I got from her back when she first registered. That’s how I find her account and I’m happy to associate it with the browser session who got the unique number in the first place and push an instruction to that browser to redirect directly to her account page.
One time I generated an auth-code for another session. Then too I got it back on the auth-gateway but I didn’t recognize the person who sent it –someone who wasn’t registered yet.
So I asked through the auth-gateway if that someone would like to create an account and I told what information I would need; name, email, and If they’d like; phone number and credit card.
He could have declined and closed the connection. But he happened to be eager to join and he instructed his auth-client to send his public key, his name, email, and phone number. He decided not to send credit card info. That’s OK, he may do that some other time if he’d like. Then I created his account and redirected his browser to his new account and our nice and friendly welcome page.
Basic ingredients as far as I can see:
site or service: The service to be authenticated, not limited to web sites, may just as well be native apps, paywalls, turnstiles or other services interfacing with the auth-gateway to connect sessions and accounts. For websites, automatic reload of authenticated browsers could happen through asynchronous polls from the browser. Or an open HTTP request waiting for server response.
auth-gateway: A standardized API to authenticate users and exchange information.
auth-client: Could be implemented by anyone, as long as it conforms to the open standard. The client is responsible for securing user-credentials. It could be local or cloud based; protected by PINs, master passwords, fingerprints and other biometrics –all up to the implementation. It could run on the computer, as a mobile app or on special hardware. It may hold basic information about the user to make signups quick and painless.
auth-code: An encoded payload of information about the session to be authenticated. This code must be accessible through a URI with a specific scheme, (E.g. auth://) to be handled by a auth-client implementation on the same device. And as a optical matrix code (like QR-code or similar) to be readable by devices with cameras. Auth-codes could also be accessible through NFC on supporting platforms.
There are obviously security implications to be resolved in this simplistic description and experts are needed to foil the phishers and to omit the men in the middle. I’m confident you can do that.
So how about we make a prototype, ratify a standard, and have everyone implement it? Who’s in?