Think of all the online accounts that you have...

Basically all your online passwords in one picture

With nearly every one of these comes a (new) password. And for most of the people out there, passwords in the end are all the same. And as they get hacked in one app, all their online presences lie open.

In the last years, a few approaches came up to tackle that problem. Apps with large userbases like Facebook, Microsoft or Google are offering social logins that link your account directly with your social media account (therefore making them your primary Identity Provider), sparing you one more password to remember. But you are still trusting on that social media account staying secure, and you are giving out a lot of data to that Identity Provider (which is up to your judgement if that is a good thing).

Another approach are password managers. With just one (hopefully more secure) password you can access randomly generated passwords to all your accounts, making each secret unique and therefore independent from your other accounts. But again you are relying on a single source of truth, and if your master password is stolen, all of your accounts are breached.You could of course add additional layers of security with Multi-Factor Authentication, but these often require additional hardware and can be costly to implement for the App creator (e.g. when you have to pay for SMS fees).

Introducing: WebAuthentication

The major OS providers Microsoft, Google and Apple have tackled this problem already a few years ago when they introduced password-less authentication on their systems. It is nowadays a de-facto standard for new devices to have some sort of fingerprint or face recognition that offers you to access your devices without remembering any passwords. And the best feature: Usually your biometric data is stored directly on the device, making it impossible to breach some database of face or finger data.

With biometrics you are the password

Now that this technology has matured and got the go-to choice for most users in their everyday life, the question arised: How do we get that into the web? And frankly, the W3C tackled exactly this question with their WebAuthn specification. The specification is currently only a draft, but most of the major players have already adopted the proposed standards and it is useable on Windows, Android, iPhone (to some extend) and MacOS already.

The basic idea is quite simple: Instead of asking for a password, the browser uses native login methods (e.g. Windows Hello, Touch ID) to verify the user. The application then gets a huge package of encrypted information that can be used to verify that it was actually the user who tried to log in (and not some hacker). After successful registration, the browser then stores a private key on the users device, not exposable in any way. The server gets the according public key and a credential ID that it can store securely instead of a password.

If you are interested in the experience from the perspective of an user, check out this demo.

How is this more secure?

Every user who logs into an app is protected by multiple layers: First, the app has to find the user in its system. The app should have stored the credential ID next to the user ID. The credential ID is useful only for the browser in which the user signed in. If the browser recognizes the credential ID, it will then prompt the user for authentication. If the user passes the authentication (e.g. by providing a security key USB stick or by using Windows Hello / Touch ID), the browser can send some verifiable data to the app. This data will then be verified by the server with the public key it got at sign-up time. If this process succeeds, then the login is successful.

A good representation of how few Authn trusts your login approach

From an app standpoint, WebAuthn offers another awesome benefit: You don't have to store any passwords. All you get from an user is a public key and a credential ID. Both work only if the user in on their device, on your page URL. So let's assume your servers get breached and all credentials are stolen. In the classic password world, this means major security risks for everyone who ever worked on your app. With WebAuthn, your users can just move on, and as long as their device and face/finger/Security Key don't get stolen, their access to your app is still safe. And all other applications where they use WebAuthn to log in are not impacted by this at all.

So can I just use this everywhere now?

WebAuthentication is an exciting protocol that offers a new level of security to users who want to take an extra step in protecting their online data. But by design, this extra step comes with a few inconveniences that your users have to take. By nature, all credentials are stored on the clients device, more specifically in the app or browser that your user has used to log into your services. That means, as soon as your users switches to a new device or to a new browser on their current device, he has to sign up again with new login credentials for your service.

For scenarios like this you will always depend on other, more universal authentication methods. Let's say an user loses their device, so there is no way to log in with the credentials that you have currently stored. In moments like this, you should always be able to fall back to e.g. email verification, or a standard password.

Generally speaking, although WebAuthn does look promising in enabling a new layer of security, it is just a tool. It is always the responsibility of the app providers to ensure a secure environment for your users, and WebAuthn should be one of many locks that you put in front of your users data.

Enough Intro talk, where can I learn more?

This article is just the kick-off to a series of technical posts about WebAuthn that I plan to launch. You can find the articles here:
Getting started with WebAuthn: The basic flow
Securing your WebAuthn server: Response validation (Coming soon)
WebAuthn Step by Step: A specification rundown in code (Coming soon)

I have also prepared the code for the demo as a learning implementation on my Github. I tried to keep the documentation as extensive as possible, so you can just read through the source code and learn more about implementing this protocol. On the GitHub page you can also find a list of resources by other parties who have written great examples of how to get started with WebAuthn. And make sure to check out the official documentation as well!