The modern password system has problems. Passwords are chosen by users, which means they may be weak, they are often reused (36% of the time), they may be compromised without the user knowing, and they leave the user responsible for security in phishing attacks. It’s reported that 1,900,000,000 usernames and passwords are stolen every year. Even two-factor authentication can’t protect the user if a phishing attack is sufficiently crafted to circumvent these measures. This is why a new system is needed to ensure user security, and that system might just be the Web Authentication API (WebAuthn).

Related: How To Solve Online Checkout Problems With a Payment Request API


First, a Little History

In December 2014, the FIDO Alliance (Fast IDentity Online)—a group of companies whose goal is to increase web security and decrease the burden of dealing with passwords—started working on Universal Authentication Factor (UAF) to handle authentication of users in a more modern, secure way. Due to lack of adoption, lack of buy-in from browser manufacturers, and missing features needed to gather support, UAF did not make a major impact on users.

1,900,000,000 usernames and passwords are stolen during phishing attacks every year.

In November 2015, work began on a new version, FIDO2. The Alliance partnered with the W3C from 2016 through 2018 to establish a series of APIs, which gathered support from major browser developers Google, Microsoft, and Mozilla. The purpose of FIDO2 and the WebAuthn API was to offer more options and flexibility for user authentication; provide a smoother, simpler experience for users; create an easier path to implementation for developers; and to ensure better security all around.

Moving Away From Passwords

The goal of the FIDO Alliance and the WC3 is to create a web experience that doesn’t rely on multi-character passwords. Is it possible to live in a world where users don’t have to physically type out their passwords to log into a website? A world where users don’t have to worry about Phishing or man-in-the-middle attacks? The FIDO Alliance and W3C strongly believe that this can happen, especially if big companies like Facebook and Amazon begin to adopt it. WebAuthn is a huge step toward a passwordless future. Moving away from passwords can revolutionize the way we look at and think about authentication.

How WebAuthn Works

Although some of the finer details of WebAuthn are complicated, the general idea is simple enough. The goal is to be able to use a trusted device to authenticate a user without having to remember a complicated, unique password for every site. This trusted device might be many things: a USB dongle, which provides a secure key proving the user’s identity (a hardware security key); a Trusted Platform Module device (TPM); a thumbprint reader on their laptop; facial identification on their phone; or even a PIN on a specific device that has already been verified. The Credential Management API (already a present standard) has been expanded to store these new credential types.

Moving away from passwords can revolutionize the way we look at and think about authentication.

Consider how registration might work with WebAuthn. A user would enter a site’s registration page and create a username, along with any other site-specific details needed. The server generates a challenge, a single-use token, used only for this registration attempt. This is transferred to the browser, which then uses the Web Authentication API to send the challenge to the authenticator. The authenticator may be the same device, or a second device such as a phone (so one could, for example, register on their desktop and use the fingerprint scanner on their phone for authentication). The server also sends domain information, which helps prevent Phishing Attacks. The authenticator asks for permission to authenticate so that users can’t be harassed, tricked, or tracked with the feature. The username data, a private/public key pair, and the domain name are stored on the authenticator.

The information is then passed back to the browser, and finally back to the server to complete the handshake. After registering, logging in is simply passing information between the server, the browser, and the authenticator to ensure everything matches. Because the domain name is stored, a Phishing attack by changing the domain name will result in a failed challenge and no information will be sent back to the server.

The implementation of WebAuthn can be done in a variety of ways. Developers may choose to use WebAuthn to validate logins only while keeping a traditional registration process. Additionally, WebAuthn is backward-compatible with U2F Security Keys/Dongles, meaning the sites that already make use of the original FIDO v1 can easily upgrade to WebAuthn and users do not need to change hardware.



Related: Progressive Web Apps Are Here and They’re Changing Everything

WebAuthn uses established public/private key security standards. The security of WebAuthn depends largely on browser/app implementations, provided web/app developers follow the specified best practices. Developers are still responsible for handling user information on the server side. Users aren’t actually sending data, such as fingerprints, to the server. Instead, the fingerprint scan unlocks an identification key, which is sent to the server after the user successfully identifies themselves on the device. The server then compares the keys and approves or rejects the login. The premise is that users are providing both a thing they have (a key) and a thing they are (their private knowledge, their face, fingerprint, etc). This provides significant security gains for users and better trust for developers.

What remains to be answered is how developers handle stolen, compromised, or replaced authenticators. Because so much of the authentication information may be tied to user’s phones, sites will need a way to remove clearance from an authenticator and transfer it to another authenticator (or have multiple authenticators associated with an account).

User Experience

Because users won’t have to remember or type in a password, they can log in and quickly start consuming site content, which could translate into more sales for ecommerce sites and more views/engagement for social media sites. If the user is on a mobile device, the experience is even better. They can take advantage of the device’s fingerprint scanner and face ID functionality, which means logging into websites is as quick as unlocking their phone. In addition, WebAuthn will give users a sense of assurance. They will know without a doubt they’re logging into a verified site and not a fake site that comprises user data. With these different use cases, the user experience will improve drastically when this technology gains traction for mainstream use. Although WebAuthn mainly targets improving security, it is also making the web experience as a whole more modern.

On mobile, users can take advantage of their device’s fingerprint and face ID functionality, which means logging into websites is as quick as unlocking their phone.



At the time of writing, the WebAuthn API is currently available on the latest versions of Chrome and Firefox, and should be released with the next version of Edge. There are no immediate plans for Safari and it will not be available natively for IE. Because of this, many sites will need to create a fallback registration and login process for older browsers and account recovery.

This technology is still very new, and although there is a demo, it doesn’t work for some use cases. However, with the support of the W3C, browser developers, and FIDO, it is a good bet that WebAuthn will quickly become a desirable solution to our password problems.

Keep In Touch

Stay up-to-date on the latest digital trends, DEG news, and upcoming events by subscribing to DEG's newsletter.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>