The W3C backed standard for passwordless authentication, commonly known as WebAuthn, has been worked on by experts from the likes of Microsoft, Google and Mozilla for several years. In early 2019 it was recommended as a standard and is being adopted by many organisations as a result. This article will take a deeper look at the adoption rate.
There are some great explanations of what WebAuthn actually is and how it works. Essentially, it leverages public key infrastructure (PKI) and “authenticators”, which securely store the private keys, used to uniquely respond to challenges from each of the “relying parties” or web sites the user wants to access. Being standards based, makes implementations, by the web browsers and server side components relatively simple and easy to maintain going forward.
WebAuthn is essentially for browser based interactions. This puts a dependency on the type and version of the underlying web browser, with an also now pretty standard dependency, of the interactions needing to occur over HTTPS. Most modern browsers now support the WebAuthn underlying API, with an updated list being maintained by Mozilla.
Browser Implementation Date
Browser implementation date, is a good starting point for our review. Without browser support, adoption is clearly going to limited. Below is a brief history of when the main browsers added support:
|Browser||Earliest version with WebAuthn support||Date Released|
|Microsoft Edge||18||June 2018|
At first glance, the competition between the three leading browser types, lead to initial supported versions all occurring within 4-6 weeks of each other in mid 2018. Apple was a slight laggard to adoption, not implementing support until a good 12 months later.
Authenticators are the components that generate and store the keys used for the relying party interactions. Each website or relying party the user wants to authenticate with using WebAuthn, requires a unique key pair. The concept to make this process unique per website, is to not only remove the use of passwords, but also avoid the anti-pattern of credential to service reuse. In the very unlikely event that a private key is compromised, only a single website would be impacted.
Authenticators fall into two main categories: platform authenticators and roaming authenticators or cross platform authenticators. Platform authenticators are typically implemented as a software component within existing operating systems and leverage things like a Trust Platform Module within the underlying hardware to store the keys. A roaming authenticator, is a separate physical component – like a USB, Bluetooth or NFC device – that can be carried between different machines that handle the web browser interactions.
Platform Authenticator Support
A platform authenticator, typically requires a user gesture, for it to be used. A gesture, is typically a “local” test of presence event, such as a fingerprint, face picture (aka faceId) or a PIN. These events, do not require data to leave the device and are used to simply “unlock” the secure environment where the OS is storing the private keys.
The main platform authenticators that have been implemented, occur within the Windows and Android operating systems. The implementation support was added in the following versions:
|Operating System||Version||Local Authentication Support||Implementation Date|
|Windows||10 (1803)||Fingerprint/Face/Pin via Windows Hello||May 2018|
|Android||7||Fingerprint/PIN/pattern via OS authentication processes||April 2019|
If running Google Chrome browser v70, on certain models of Mac, that have a Touch Bar enabled, a local ceremony can be used to authenticate via TouchId to generate and retrieve generate WebAuthn key pairs.
Roaming Authenticator Support
Roaming authenticators, are physical peripherals, separate to the device accessing the relying party or website, that generate and store the key pairs. Whilst many of the original FIDO v1 U2F (Universal Second Factor) style keys could perform this role, but depending on implementation, these devices may not be able to store the optional userid that is sometimes added to the key pair meta data, that allows for a username-less experience to the relying party.
The FIDO Alliance lists over 70 authenticators, certified against the FIDO 2 / WebAuthn standard. Google themselves manufacture and release the Titan security key, whilst Yubico and SoloKeys offer alternatives that promote WebAuthn support. Google also recently released a proof of concept level project called OpenSK, to encourage development of compliant keys on different hardware.
The following is a search word analysis for “webauthn” globally, for the last 5 years:
Source: trends.google.com – “WebAuthn” search term analysis, last 5 years, world wide.
The trends analysis, indicates the max peak (indicated by the 100), was achieved back in Feb/March 2019 – just when the W3C specification was standardised. The search interest post this date, is certainly above what occurred pre-standardisation, but does not seem to indicate a large upward swing.
An interesting angle, is that of the top geographies showing interest. The top 5 areas do not include North America:
Source: trends.google.com – “WebAuthn” search term analysis, last 5 years, world wide, geographical breakdown
If we overlay comparison against FIDO (Fast Identity Online), which was one of the earlier incarnations of passwordless/crypto authentication, we can see there is a distinct level of interest in the two approaches:
Source: trends.google.com – “WebAuthn” (blue) -v- FIDO (red) search term analysis, last 5 years, world wide.
Although FIDO has a larger trend history, this peaked in 2017 and is steadily in decline.
A basic search on LinkedIn in February 2020, returns approximately 20 jobs world wide, with a key requirement of WebAuthn skills or knowledge. An equivalent search for FIDO vacancies, results in over 900 vacancies globally. The latter search, is clearly more generic in nature, but is a good basic indicator of current labour market demand.
The following are the ten most forked repositories on Github that relate to WebAuthn:
|Position||Repository||Number of Forks||Number of Stars||Last Updated|
|1||solokeys/solo||136||1.3k||Feb 18th 2020|
|2||w3c/webauthn||101||533||Feb 20th 2020|
|3||google/OpenSK||97||1.5k||Feb 21st 2020|
|4||google/webauthndemo||66||207||Sept 8th 2019|
|5||fido-alliance/webauthn-demo||63||274||Oct 23rd 2019|
|6||abergs/fido2-net-lib||61||265||Feb 18th 2020|
|7||duo-labs/webauthn||52||415||Feb 1st 2020|
|8||Yubico/yubikey-manager||51||261||Feb 19th 2020|
|9||duo-labs/py_webauthn||48||170||Feb 10th 2020|
|10||Yubico/java-webauthn-server||47||132||Feb 17th 2020|
So what does the above from github tell us? A high level commentary could include:
- 2 of the repo’s are demo related
- 1 is the actual specification text
- 5 are from vendors
- 1 is for integration
- 8/10 have received updates in the last 30 days
It seems that the majority of github interaction is probably for assessment and proof of concept related work, with vendors currently acting in evangelism and community support work.
The Gartner Hype Cycle Identity & Access Management, last updated in August 2019, positions FIDO within the “Peak of Inflated Expectations” bucket. FIDO in this case, also covers U2F and UAF protocols as well as WebAuthn/FIDO2. Mainstream adoption is listed as being 2-5 years away.
WebAuthn is an emerging concept, in the quest for the passwordless holy grail. Implementation support by the major browsers, has certainly kick started attention and likely started a phase of enterprise pilot’s and proof of concepts.