What Is Web Authentication and How Does It Work?
Many types of web authentication methods exist that can help you keep your users' data safe. These methods protect against phishing attacks and data breaches by verifying the user's identity, ensuring that they are who they claim to be. Through modern web authentication methods such as multi-factor authentication (MFA), and two-factor authentication (2FA) that combine different methods, securing access to web-based applications and resources can be hassle-free and trustworthy.
What are the Three Types of Authentication?
Something you know: Passwords or PINs
Something you have: A mobile device, token, or one-time passcodes (OTPs)
Something you are: Biometrics such as TouchID or FaceID
Since mid 2016, a group of security professionals and researchers from across the industry have been working on a new way to handle authentication known as web authentication API. This technology uses web-based authentication to securelyprove one’s identity on the internet without the help of passwords.
What is Web Authentication API?
The new standard known as Web Authentication, or WebAuthn for short, is a credential management API that will be built directly into popular web browsers. This software allows users to register and authenticate with web applications using an authenticator such as a phone, hardware security keys, or TPM (Trusted Platform Module) devices.
This means with devices like a phone or a TPM, where a user can provide us with biometric verification, we can use WebAuthn to replace traditional passwords. Aside from user verification, we can also confirm ‘user presence.’ So, if users have a U2F token like a Yubikey, we can handle that second factor of authentication through WebAuthn API as well.
While WebAuthn is a fairly new spec, it is heavily based on a relatively old one, at least in “Internet years.” The FIDO Alliance began working on a similar web authentication API Standard in 2014 called UAF, Universal Authentication Factor. The specification for UAF fell short in some ways: It seems like there was never a real push to have the necessary functionality added to major browsers, so developers that wanted to implement it were tasked with working around that lack of native support.
On top of that, there was little reference for how to implement the steps to make UAF work properly on Android and iOS devices. At the time of publication, the best practical UAF reference was this implementation open-sourced by eBay.
Unlike its predecessor, WebAuthn should be here to stay. Although the fine points of the spec are complex, WebAuthn has been easy to implement in practice. At the time of writing this, both Chrome and Firefox have the data types necessary for WebAuthn, and Firefox’s Nightly Build can create and request credentials. We’ll talk a bit later about what this new standard could mean for the future of passwords (sorry, they’re probably not going away tomorrow), but first, a bit more about the core components of the WebAuthn API.
How do Web Authentications API register and authenticate?
While WebAuthn is drafted to be an open-ended credential creation and management API capable of making many types of credentials, it is written to handle registration and authentication to a web application. The credentials created through the WebAuthn API rely on strong cryptographic principles and asymmetric encryption. So, when we talk about credential registration and authentication, know that the credentials we are using are actually public and private key pairs.
Registration
During registration, a user is creating a credential with an authenticator and then proving to the web application’s owner, called the relying party, that the credential and authenticator used to create it are trustworthy. Proving this allows the relying party to use the credential created in lieu of a conventional password in cases where there is user verification, and as a replacement for conventional U2F in cases where we can only prove user presence.
There are more than a few different cases for how WebAuthn would work in practice, but the most common example is this: A user visits a website, let’s say cat-facts.com, on their laptop and goes to register an account. After pressing a button to begin registration on the site, they receive a prompt on their phone saying, “Register with cat-facts.com.”
Once they’ve accepted the request, the user would be asked to perform an “authorization gesture,” such as typing in a PIN or biometric action that is associated with the account they are creating. After providing this, the website on the laptop would display something to the effect of “Registration complete!”
The user can now log in to cat-facts.com using the same phone and authorization gesture.
Authentication
Authentication, also known as assertion, since we are asserting the ownership of a credential, occurs after we have registered a credential with a website. Since the credential is just a keypair, the relying party can send some data to the user to verify their identity via the user’s authenticator. If they are who they say they are, the data will return signed by the credential private key. This action, in part, authenticates the user to the relying party.
Let’s consider a different scenario for how we can use WebAuthn to handle authentication after a user has registered with the site example.com. Let’s assume they’ve registered a second account as well and, to make things more interesting, that they are browsing on their phone. The user navigates to example.com on their phone and chooses the option to login. They are shown a list of their two accounts, choose one to log in to, and then they’re prompted to enter a PIN or biometric associated with the account. After this is given, example.com logs the user into the selected account.
What are security concerns with Web Authentication?
Most security issues lie with the implementation of the WebAuthn spec by developers. If a developer doesn’t consider checking for things like replay attacks or making sure that the authenticator hasn’t been compromised in some way, then attacks are possible. Most concerns regarding the authenticator and manufacturer can be mitigated by diligence on the part of the developer.
What does Web Authentication API mean for passwords?
The big thing that WebAuthn wants to provide is biometric multi-factor authentication based on “Something a user is.” A user (in most cases) has a voice, a fingerprint, or a retina, that is unique to them. Something most users also have nowadays is a biometric device, like a smartphone, that can use this data to create and manage credentials that only the user can access through these unique traits.
Since your phone is much better at making and storing passwords than you are, we can replace the standard website password using the WebAuthn spec. It is built with this in mind as its core feature, but currently only supports the physical method of two-factor authentication (“something a user has,” like a hardware security token), since no phones currently support WebAuthn.
This is not to say either that WebAuthn cannot be used for the multi-factor authentication method of something a user knows. It can (once the specification is implemented) do that too! Take, for example, a user entering a PIN instead of a biometric to authenticate with a website. This is something a user knows, but handled via the WebAuthn spec. Unlike WebAuthn’s predecessor, FIDO UAF, the spec allows for a lot more versatility.
Also, unlike FIDO UAF, there are a lot of heavyweights supporting it, including Google, Microsoft and Mozilla. This makes me hopeful that this spec will actually begin to be adopted. A good sign of these companies actively being involved in WebAuthn’s development is that the spec already explains how it will integrate with Android Key Store and Android SafetyNet, and with Google engineers contributing to the spec draft, they’ll probably add support soon. As of now, Google engineers have developed a new solution with plans to gradually discontinue Android SafetyNet within the next year, giving users enough time to migrate to the new Play Integrity API and avoid disruptions.
But Google was likely thinking about this issue for a while now. In the beginning of 2017, Google began working on a specification regarding a credential manager API to handle credential storage. However, the only credentials it talks about in this version of the credential manager are password and federated credentials. Google actually released documentation on using this credential management API in Chrome, and the same API is being modified (in Chrome) to include support for WebAuthn credentials.
So don’t start deleting your passwords yet, because WebAuthn still needs a bit of work. While it looks like the WebAuthn API should be available on Firefox and Chrome in the coming months, I don’t think we’ll see it replace passwords very soon. I do hope developers and companies start to implement it as a replacement for existing two-factor authentication code they may have in their site, because when phones begin to support WebAuthn requests, it should be quick to switch over support for user verification. After all, the best website authentication method is the one that will focus on offering a balance between ease of use, security, and compliance.
What are more examples of WebAuthn in action?
The Duo Labs team wrote a couple proof of concepts to both teach ourselves and help others see how WebAuthn should work in practice. After receiving some very helpful advice from J.C. Jones, one of the authors of the standard, I put together a bare bones web application written in Go that demonstrates the basics of Webauthn Registration and Authentication. The code is available to try out, currently only via the Firefox Nightly Build, at webauthn.io and the source code is available on GitHub if you want to run the code locally.
I hope to have another blog post available soon with a more technical look at this innovate web authentication software, but in the meantime, if you’re feeling excited and ready to take a deeper dive into WebAuthn, then I encourage you to check out the W3C working draft. If you have any questions about web authentication and WebAuthn, please feel free to reach out to me on Twitter or GitHub.