WebAuthn: Difference between revisions
Cleanup: remove deletion notice and missing templates |
|||
| (62 intermediate revisions by 30 users not shown) | |||
| Line 1: | Line 1: | ||
{{About|the W3C standard|passwordless authentication credential|Passkey (credential)|other methods of authentication used on the web|Authentication#In computer science}} | |||
{{Technical|date=February 2024}} | {{Technical|date=February 2024}} | ||
{{Infobox technology standard | {{Infobox technology standard | ||
| title = Web Authentication | | title = Web Authentication | ||
| image = | | image = WebAuthn Color Logo.svg | ||
| caption = | | caption = | ||
| year_started = 2013 | | year_started = 2013 | ||
| Line 32: | Line 29: | ||
| committee = [[Web Authentication Working Group]] | | committee = [[Web Authentication Working Group]] | ||
| abbreviation = WebAuthn | | abbreviation = WebAuthn | ||
| preview = Level 3 ( | | preview = Level 3 (Candidate Recommendation) | ||
| preview_date = {{Start date| | | preview_date = {{Start date|2026|05|26|df=y}} | ||
| base_standards = {{Plainlist| | | base_standards = {{Plainlist| | ||
* [[HTML5 File API|File API]] | * [[HTML5 File API|File API]] | ||
| Line 41: | Line 38: | ||
}} | }} | ||
'''Web Authentication''' ('''WebAuthn''') is a [[web standard]] published by the [[World Wide Web Consortium]] (W3C).<ref name="W3C-WebAuthn-Level-1"/><ref>{{cite web |url=https://www.w3.org/blog/webauthn/ |title=Web Authentication Working Group |publisher=[[World Wide Web Consortium]] |access-date=2018-05-11}}</ref><ref>{{cite episode |title=What is WebAuthn |series=TechStuff |publisher=[[iHeartMedia]] |series-link=HowStuffWorks#TechStuff |first=Jonathan |last=Strickland |date=18 March 2019 |url=https://www.iheart.com/podcast/105-techstuff-26941194/episode/what-is-webauthn-30705004/ |minutes=20:35 |access-date=20 March 2019}}</ref> | '''Web Authentication''' ('''WebAuthn''') is a [[web standard]] published by the [[World Wide Web Consortium]] (W3C).<ref name="W3C-WebAuthn-Level-1"/><ref>{{cite web |url=https://www.w3.org/blog/webauthn/ |title=Web Authentication Working Group |publisher=[[World Wide Web Consortium]] |access-date=2018-05-11 |archive-date=15 May 2016 |archive-url=https://web.archive.org/web/20160515104033/https://www.w3.org/blog/webauthn/ |url-status=live }}</ref><ref>{{cite episode |title=What is WebAuthn |series=TechStuff |publisher=[[iHeartMedia]] |series-link=HowStuffWorks#TechStuff |first=Jonathan |last=Strickland |date=18 March 2019 |url=https://www.iheart.com/podcast/105-techstuff-26941194/episode/what-is-webauthn-30705004/ |minutes=20:35 |access-date=20 March 2019 |archive-date=25 June 2021 |archive-url=https://web.archive.org/web/20210625115545/https://www.iheart.com/podcast/105-techstuff-26941194/episode/what-is-webauthn-30705004/ |url-status=live }}</ref> | ||
It defines an [[API]] that websites use to [[Authentication#In computer science|authenticate]] with WebAuthn credentials ('' | It defines an [[API]] that websites use to [[Authentication#In computer science|authenticate]] with WebAuthn credentials (commonly known as ''[[passkey (credential)|passkeys]]''<ref>{{cite web |title=White Paper: Multi-Device FIDO Credentials |url=https://fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-Cases-March24.pdf |publisher=[[FIDO Alliance]] |access-date=20 May 2024 |page=6 |date=March 2022 |archive-date=16 June 2024 |archive-url=https://web.archive.org/web/20240616202812/https://fidoalliance.org/wp-content/uploads/2022/03/How-FIDO-Addresses-a-Full-Range-of-Use-Cases-March24.pdf |url-status=live }}</ref><ref name="docsrs-webauthnrs">{{cite web |last1=Brown |first1=William |title=webauthn-rs docs |url=https://docs.rs/webauthn-rs/latest/webauthn_rs/#what-is-a-passkey |website=Docs.rs |publisher=Kanidm Identity Management Project |access-date=3 July 2025 |date=April 2024 |archive-url=https://web.archive.org/web/20250612151121/https://docs.rs/webauthn-rs/latest/webauthn_rs/#what-is-a-passkey |archive-date=12 June 2025}}</ref>) and outlines what WebAuthn authenticators should do. | ||
It solves many of the issues of traditional [[password]]-based authentication by verifying the user's identity with [[digital signatures]].<ref name="imperialviolet-webauthn">{{cite web |last=Langley |first=Adam |date=2024-12-23 |title=A Tour of WebAuthn |url=https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html |access-date=2025-08-13 |website=Imperial Violet}}</ref> | It solves many of the issues of traditional [[password]]-based authentication by verifying the user's identity with [[digital signatures]].<ref name="imperialviolet-webauthn">{{cite web |last=Langley |first=Adam |date=2024-12-23 |title=A Tour of WebAuthn |url=https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html |access-date=2025-08-13 |website=Imperial Violet}}</ref> | ||
Although WebAuthn is often touted as a complete replacement for passwords, most websites that implement it continue to use passwords in some capacity.<ref name="arstechnica-not-usable">{{cite web |last1=Goodin |first1=Dan |title=Passkey technology is elegant, but | Although WebAuthn is often touted as a complete replacement for passwords, most websites that implement it continue to use passwords in some capacity.<ref name="arstechnica-not-usable">{{cite web |last1=Goodin |first1=Dan |title=Passkey technology is elegant, but it's most definitely not usable security |date=30 December 2024 |url=https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ |publisher=Ars Technica |access-date=3 July 2025 |archive-date=3 July 2025 |archive-url=https://web.archive.org/web/20250703130434/https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ |url-status=live }}</ref> | ||
To use WebAuthn, users require a compatible authenticator. The standard does not specify how to store the [[private key|keys]] required for signing, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the [[operating system]] of the device. Common platform authenticators include [[Android (operating system)|Android]], [[Apple Keychain]] and [[Windows Hello]]. These make use of hardware security features (such as [[trusted execution environment|TEE]] and [[Trusted Platform Module|TPM]]), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). Most [[smartphones | To use WebAuthn, users require a compatible authenticator. The standard does not specify how to store the [[private key|keys]] required for signing, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the [[operating system]] of the device. Common platform authenticators include [[Android (operating system)|Android]], [[Apple Keychain]] and [[Windows Hello]]. These make use of hardware security features (such as [[trusted execution environment|TEE]] and [[Trusted Platform Module|TPM]]), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). Most [[smartphones]] can be used as roaming authenticators, and dedicated physical [[security token|security keys]] are also used. WebAuthn is effectively backward compatible with [[FIDO Alliance|FIDO]] [[Universal 2nd Factor]] (U2F) as they both use the [[CTAP]] protocol.<ref>{{cite web |title=WebAuthn / CTAP: Modern Authentication |url=https://www.w3.org/Security/201812-Auth-ID/05_-_Day_1_-_Understanding_WebAuthn,_CTAP,_EAT,_FIDO_and_Authenticators.pdf |publisher=[[World Wide Web Consortium]] |access-date=11 March 2019 |date=10 December 2018 |archive-date=4 December 2020 |archive-url=https://web.archive.org/web/20201204162731/https://www.w3.org/Security/201812-Auth-ID/05_-_Day_1_-_Understanding_WebAuthn,_CTAP,_EAT,_FIDO_and_Authenticators.pdf |url-status=live }}</ref> [[Password manager]]s can also be used as an authenticator, often with cloud sync.<ref>{{Cite web |date=2023-06-01 |title=Will Passkeys Kill Password Managers? |url=https://www.corbado.com/blog/passkeys-vs-password-managers |access-date=2025-09-18 |website=Corbado |language=en}}</ref> Where credentials sync is not viable or possible, WebAuthn Hybrid Transport can be used to access credentials stored on another authenticator such as a smartphone.<ref name="Corbado-HybridTransport">{{Cite news |date=2023-11-08 |title=WebAuthn Passkey QR Codes & Bluetooth: Hybrid Transport |url=https://www.corbado.com/blog/webauthn-passkey-qr-code |access-date=2025-09-18 |work=Corbado |language=en}}</ref> | ||
Like legacy U2F, WebAuthn is resistant to [[phishing|phishing attacks]]<ref>{{cite web |last1=Kan |first1=Michael |title=Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise |url=https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |publisher=PC Magazine |access-date=8 March 2019 |date=7 March 2019}}</ref> as the authenticator only offers credentials that were registered on the [[same-origin policy|same website]]. However, unlike U2F, WebAuthn can be implemented in a [[passwordless authentication|passwordless]] manner.<ref>{{Cite web |date=2018-04-10 |title=Practical passwordless authentication comes a step closer with WebAuthn |url=https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |access-date=2024-10-16 |website=[[Ars Technica]] |language=en-US}}</ref> Moreover, a roaming hardware authenticator resists malware, since the keys are stored on a separate device, which prevents the malware from accessing them directly. | Like legacy U2F, WebAuthn is resistant to some [[phishing|phishing attacks]]<ref>{{cite web |last1=Kan |first1=Michael |title=Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise |url=https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |publisher=PC Magazine |access-date=8 March 2019 |date=7 March 2019 |archive-date=8 March 2019 |archive-url=https://web.archive.org/web/20190308035745/https://www.pcmag.com/news/367026/google-phishing-attacks-that-can-beat-two-factor-are-on-the |url-status=live }}</ref> as the authenticator only offers credentials that were registered on the [[same-origin policy|same website]]. However, unlike U2F, WebAuthn can be implemented in a [[passwordless authentication|passwordless]] manner.<ref>{{Cite web |date=2018-04-10 |title=Practical passwordless authentication comes a step closer with WebAuthn |url=https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |access-date=2024-10-16 |website=[[Ars Technica]] |language=en-US |archive-date=1 January 2025 |archive-url=https://web.archive.org/web/20250101102456/https://arstechnica.com/gadgets/2018/04/practical-passwordless-authentication-comes-a-step-closer-with-webauthn/ |url-status=live }}</ref> Moreover, a roaming hardware authenticator resists malware, since the keys are stored on a separate device, which prevents the malware from accessing them directly. | ||
The WebAuthn Level 1 and 2 standards were published as [[W3C recommendation|W3C Recommendations]] on 4 March 2019 and 8 April 2021 respectively.<ref name="W3C-WebAuthn-Level-1">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Liao |editor7-first=Angelo |editor8-last=Lindemann |editor8-first=Rolf |editor9-last=Lundberg |editor9-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 1 (latest) |url=https://www.w3.org/TR/webauthn-1/ |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019}}</ref><ref name="W3C-WebAuthn-announce">{{cite web |title=W3C and FIDO Alliance Finalize Web Standard for Secure, Passwordless Logins |url=https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019 |date=4 March 2019}}</ref><ref name="W3C-WebAuthn-Level-2">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Lindemann |editor7-first=Rolf |editor8-last=Lundberg |editor8-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 2 |url=https://www.w3.org/TR/webauthn-2/ |access-date=27 November 2022 |publisher=[[World Wide Web Consortium]] |publication-date=8 April 2021 |edition=Latest}}</ref> A Level 3 specification | The WebAuthn Level 1 and 2 standards were published as [[W3C recommendation|W3C Recommendations]] on 4 March 2019 and 8 April 2021 respectively.<ref name="W3C-WebAuthn-Level-1">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Liao |editor7-first=Angelo |editor8-last=Lindemann |editor8-first=Rolf |editor9-last=Lundberg |editor9-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 1 (latest) |url=https://www.w3.org/TR/webauthn-1/ |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019 |archive-date=14 March 2019 |archive-url=https://web.archive.org/web/20190314015005/https://www.w3.org/TR/webauthn-1/ |url-status=live }}</ref><ref name="W3C-WebAuthn-announce">{{cite web |title=W3C and FIDO Alliance Finalize Web Standard for Secure, Passwordless Logins |url=https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en |publisher=[[World Wide Web Consortium]] |access-date=4 March 2019 |date=4 March 2019 |archive-date=4 March 2019 |archive-url=https://web.archive.org/web/20190304132257/https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en |url-status=live }}</ref><ref name="W3C-WebAuthn-Level-2">{{cite web |editor1-last=Balfanz |editor1-first=Dirk |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Hodges |editor3-first=Jeff |editor4-last=Jones |editor4-first=J.C. |editor5-last=Jones |editor5-first=Michael B. |editor6-last=Kumar |editor6-first=Akshay |editor7-last=Lindemann |editor7-first=Rolf |editor8-last=Lundberg |editor8-first=Emil |title=Web Authentication: An API for accessing Public Key Credentials Level 2 |url=https://www.w3.org/TR/webauthn-2/ |access-date=27 November 2022 |publisher=[[World Wide Web Consortium]] |publication-date=8 April 2021 |edition=Latest |archive-date=4 June 2019 |archive-url=https://web.archive.org/web/20190604093843/https://www.w3.org/TR/webauthn-2/ |url-status=live }}</ref> A Level 3 specification progressed through several Candidate Recommendation Snapshots during 2026,<ref name="W3C-WebAuthn-Level-3-CR">{{Cite web |title=W3C Invites Implementations of Web Authentication: An API for accessing Public Key Credentials Level 3 |url=https://www.w3.org/news/2026/w3c-invites-implementations-of-web-authentication-an-api-for-accessing-public-key-credentials-level-3/ |publisher=[[World Wide Web Consortium]] |date=13 January 2026 |access-date={{subst:CURRENTDAY}} September 2026 }}</ref><ref name="W3C-WebAuthn-Level-3-CR-update">{{Cite web |title=Updated Candidate Recommendation: Web Authentication: An API for accessing Public Key Credentials Level 3 |url=https://www.w3.org/news/2026/updated-candidate-recommendation-web-authentication-an-api-for-accessing-public-key-credentials-level-3/ |publisher=[[World Wide Web Consortium]] |date=26 May 2026 |access-date={{subst:CURRENTDAY}} September 2026 }}</ref> and in July 2026 the W3C proposed advancing it to full Recommendation status.<ref name="W3C-WebAuthn-Level-3-propose-rec">{{Cite web |title=Proposed Advancement of Web Authentication: An API for accessing Public Key Credentials Level 3 to W3C Recommendation |url=https://www.w3.org/news/2026/proposed-advancement-of-webauthn-3-to-w3c-recommendation/ |publisher=[[World Wide Web Consortium]] |date=20 July 2026 |access-date={{subst:CURRENTDAY}} September 2026 }}</ref> | ||
== Background == | == Background == | ||
The combination of username and password has been the standard mechanism for users to prove to a website that they are a specific person since the dawn of web-based services.<ref>{{Cite book |last1=Bonneau|first1=Joseph|last2=Herley|first2=Cormac|last3=Oorschot|first3=Paul C. van|last4=Stajano|first4=Frank|chapter=The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes |date=2012|title=2012 IEEE Symposium on Security and Privacy|pages=553–567|doi=10.1109/SP.2012.44 |bibcode=2012sp...conf...46B |isbn=978-1-4673-1244-8 }}</ref> However, password-based authentication has been known to be flawed for many years, even decades, with most issues relating to poor practices on either the user side or the server side. Users routinely reuse passwords across services (which exposes them to [[credential stuffing]]),<ref>{{Cite book |last1=Wang|first1=Chun|last2=Jan|first2=Steve T.K.|last3=Hu|first3=Hang|last4=Bossart|first4=Douglas|last5=Wang|first5=Gang|title=Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy |chapter=The Next Domino to Fall: Empirical Analysis of User Passwords across Online Services |date=2018-03-13 |language=en|publisher=ACM|pages=196–203|doi=10.1145/3176258.3176332|isbn=978-1-4503-5632-9}}</ref> choose weak passwords that can be brute-forced and predicted in a short amount of time<ref>{{Cite book |last1=Mazurek|first1=Michelle L.|last2=Komanduri|first2=Saranga|last3=Vidas|first3=Timothy|last4=Bauer|first4=Lujo|last5=Christin|first5=Nicolas|last6=Cranor|first6=Lorrie Faith|last7=Kelley|first7=Patrick Gage|last8=Shay|first8=Richard|last9=Ur|first9=Blase|title=Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security - CCS '13 |chapter=Measuring password guessability for an entire university |date=2013 |language=en|publisher=ACM Press|pages=173–186|doi=10.1145/2508859.2516726|isbn=978-1-4503-2477-9}}</ref>, and store them in insecure ways that allows for their disclosure (for example writing them down on a piece of paper or a document),<ref>{{Cite conference|publisher=USENIX Association|isbn=978-1-939133-10-6|pages=13–30|last1=Habib|first1=Hana|last2=Naeini|first2=Pardis Emami|last3=Devlin|first3=Summer|last4=Oates|first4=Maggie|last5=Swoopes|first5=Chelse|last6=Bauer|first6=Lujo|last7=Christin|first7=Nicolas|last8=Cranor|first8=Lorrie Faith|title=User behaviors and attitudes under password expiration policies|location=Baltimore, MD|date=2018|conference=Fourteenth Symposium On Usable Privacy and Security (SOUPS 2018)|book-title=}}</ref> with each of those contributing to the likelihood of credentials and account compromise. Likewise, servers often deal with passwords improperly, both while storing them in [[Database|databases]], and while processing them. Flaws include plain-text storage, lack of [[Salt (cryptography)|salted]] [[Hash (cryptography)|hashing]] (or more advanced schemes for at-rest credentials),<ref>{{Cite web |title=Password Storage - OWASP Cheat Sheet Series |url=https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html |access-date=2026-11-01 |website=cheatsheetseries.owasp.org}}</ref> arbitrary restrictions on password length and [[charset]], mandatory ineffective password changes, and deliberate incompatibility with [[Password manager|password managers]] (for instance, by preventing passwords to be pasted).<ref>{{Cite journal |last1=Lee |first1=Kevin |last2=Sjöberg |first2=Sten |last3=Narayanan |first3=Arvind |date=2022 |title=Password policies of most top websites fail to follow best practices |url=https://www.usenix.org/conference/soups2022/presentation/lee |journal=Soups '22 |language=en |pages=561–580 |isbn=978-1-939133-30-4}}</ref> | |||
As a result, in 2012, [[Google]] alongside [[Yubico]] started working on a standard called [[Universal 2nd Factor|Universal 2 Factor]] (U2F)<ref>{{Cite web |title=Yubico Company Timeline|url=https://www.yubico.com/why-yubico/yubico-innovation-history/|access-date=2026-06-04|website=Yubico|language=en-US}}</ref> that would allow websites to programmatically verify a second-factor about the user by verifying the presence of hardware-based tokens (like [[smart card]]s) on the user. This standard was considered an improvement over existing solutions like time-based [[one-time password]] ([[TOTP - Time-based One-time Password Algorithm|TOTP]]) or SMS-based authentication that still left the user vulnerable to sophisticated [[phishing]] campaigns. The standard was later adopted into a larger industry-wide collaboration called the [[FIDO Alliance|FIDO (Fast IDentity Online) Alliance]]. The first draft for this proposed standard was published in 2014.<ref>{{Cite web |date=2014-12-09|title=FIDO Alliance Publishes Final FIDO 1.0 Specifications, First Industry Standards for Universal Strong Authentication|url=https://www.yubico.com/press-releases/fido-alliance-publishes-final-fido-1-0-specifications-first-industry-standards-for-universal-strong-authentication/|access-date=2026-06-04|website=Yubico|language=en-US}}</ref> In 2015, the FIDO Alliance started developing the [[FIDO2 Project|FIDO 2 Project]], releasing a proposed standard where they sought to improve upon the existing U2F standard by addressing many of its weaknesses.<ref>{{Cite web |date=2015-09-04|title=FIDO Complete Spec 2015-09-04|url=https://fidoalliance.org/specs/fido-v2.0-ps-20150904/FIDO-COMPLETE-v2.0-ps-20150904.pdf|access-date=5 June 2026|website=Fido Alliance}}</ref> For example, the U2F standard still required the use of passwords alongside a second factor which still left websites vulnerable to password leaks and other similar attacks that were common against passwords.<ref name=":0">{{Cite book |last1=Ghorbani Lyastani|first1=Sanam|last2=Schilling|first2=Michael|last3=Neumayr|first3=Michaela|last4=Backes|first4=Michael|last5=Bugiel|first5=Sven|title=2020 IEEE Symposium on Security and Privacy (SP) |chapter=Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication |date=May 2020 |publisher=IEEE|pages=268–285|doi=10.1109/SP40000.2020.00047|bibcode=2020sp...conf...24G |isbn=978-1-7281-3497-0}}</ref> Additionally, the U2F specification only verified the second factor device and did not perform any user authentication.<ref name=":0" /> This meant that if the second factor device had been stolen or lost anyone with access to the U2F device would be able to bypass the second factor of authentication for accounts linked to the device.<ref name=":0" /> | |||
In November 2015, the FIDO Alliance submitted the first version of FIDO 2 to the World Wide Web Consortium as a proposed web standard.<ref>{{Cite web |date=2015-11-20|title=W3C Welcomes the FIDO 2.0 Member Submission|url=https://www.w3.org/blog/2015/w3c-fido/|access-date=2026-06-05|website=W3C|language=en}}</ref> In 2016, the W3C established a separate [[Web Authentication Working Group|W3C Web Authentication Working Group]] to help write a standard for the new FIDO 2 project's authentication framework such that it could be integrated into browsers by default.<ref>{{Cite web |title=Web Authentication Working Group Charter|url=https://www.w3.org/2015/12/web-authentication-charter.html|access-date=2026-06-04|website=www.w3.org}}</ref> The standard was adopted by major browser vendors in late 2018 and early 2019, with Chrome supporting the standard in version 67, Firefox in version 60 and Safari in version 13.<ref>{{Cite web |date=2026-02-19|title=Web Authentication API - Web APIs {{!}} MDN|url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API|access-date=2026-06-04|website=MDN Web Docs|language=en-US}}</ref> In 2019, the FIDO 2 project alongside the W3C Web Authentication Working Group released the first version of the WebAuthn specification based on the FIDO 2 project as a W3C recommendation. Subsequently, the standard has gone through two revisions, being called Level 1, Level 2 with a Level 3 revision still being considered a Candidate Recommendation {{As of|2026|June|lc=y}},<ref>{{Cite web |title=Web Authentication: An API for accessing Public Key Credentials - Level 3|url=https://www.w3.org/TR/webauthn-3/Overview.html|access-date=2026-06-04|website=www.w3.org}}</ref> meaning that it is considered mature and feature complete and is ready for implementation and testing by interested parties.<ref>{{Cite web |title=W3C Process Document|url=https://www.w3.org/policies/process/20250818/Overview.html|access-date=2026-06-04|website=www.w3.org}}</ref> | |||
== Passkey branding == | |||
{{main|Passkey (credential)}} | |||
= | [[File:Bitwarden Passkey window screenshot.png|thumb|upright=1.2|Here shown the usage of passkey as a term to refer to WebAuthn credential ([[Bitwarden]] for [[Pixiv]])]] | ||
''Passkey'' is the [[de facto]] [[Technical language|non-technical]] term for a saved sign-in credential, a piece of [[cryptographic]] information that is capable of being used to authenticate a user using the WebAuthn standard.<ref name="docsrs-webauthnrs"/><ref name="imperialviolet-webauthn"/> Most user interfaces that support using WebAuthn refer to it as supporting ''passkeys''.<ref name="arstechnica-not-usable"/> | |||
Due to the open-ended nature of the WebAuthn specification, a passkey can be stored on software or hardware that is capable of authenticating a user. This includes technology like [[Windows Hello]] which works by using facial recognition to authenticate users,<ref>{{Cite web |last=|title=Support for Passkeys in Windows|url=https://learn.microsoft.com/en-us/windows/security/identity-protection/passkeys/|access-date=2026-06-06|website=learn.microsoft.com|language=en-us}}</ref><ref>{{Cite web |title=Configure Windows Hello - Microsoft Support|url=https://support.microsoft.com/en-us/windows/configure-windows-hello-dae28983-8242-bb2a-d3d1-87c9d265a5f0|access-date=2026-06-06|website=support.microsoft.com}}</ref> [[Bitwarden]] which authenticates users through a [[browser extension]]<ref>{{Cite web |title=Log In With Passkeys|url=https://bitwarden.com/help/login-with-passkeys/|access-date=2026-06-06|website=Bitwarden|language=en}}</ref> or [[YubiKey]]s that allow a user to authenticate using a physical hardware token.<ref>{{Cite web |last=|first=|last2=|title=Stop changing weak passwords. Start replacing them with passkeys|url=https://www.pcworld.com/article/2591499/stop-changing-weak-passwords-start-replacing-them-with-passkeys.html|access-date=2026-06-06|website=PCWorld|language=en}}</ref> The cryptographic keys stored by the software are only available to use for the browser once the software or hardware has authenticated the user.<ref name="arstechnica-not-usable"/> | |||
When Apple first prominently introduced passkeys to the public in 2022,<ref>{{cite news |last1=Clemons|first1=Taylor|title=WWDC 2022: Apple announces Passkey feature to eliminate passwords across platforms|url=https://www.zdnet.com/article/wwdc-2022-apple-announces-passkey-feature/|access-date=4 July 2025|publisher=ZD Net|date=6 June 2022|archive-date=6 June 2023|archive-url=https://web.archive.org/web/20230606212207/https://www.zdnet.com/article/wwdc-2022-apple-announces-passkey-feature/|url-status=live}}</ref> they emphasized integrations with their own products. This, combined with the lack of clear communication from other companies, led to speculation that passkeys were proprietary to Apple.<ref>{{cite news |last1=Shakir|first1=Umar|title=Reminder: passkeys are not just from Apple|url=https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fido-alliance-passwordless-google-microsoft|access-date=4 July 2025|publisher=The Verge|date=6 August 2022|archive-date=24 September 2023|archive-url=https://web.archive.org/web/20230924231545/https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fido-alliance-passwordless-google-microsoft|url-status=live}}</ref> As browsers and websites began to implement WebAuthn, the inconsistent feature-sets have often resulted in a variety of understandings of what exactly counted as a passkey.<ref name="arstechnica-not-usable"/> | |||
== Overview == | == Overview == | ||
The WebAuthn standard provides a mechanism for a device or a program, known as the "authenticator") to verify a user's identity to a website through their web browser by confirming that the user possesses the device.<ref name="W3C-WebAuthn-Level-1" /> To do this in a secure manner, the standard defines two events, the registration ceremony and the authentication ceremony. During these events the authenticator communicates with the website through the web browser to register itself as a device the user possesses and proves to the website that the user still possesses the device respectively.<ref name="W3C-WebAuthn-Level-1" /> | |||
===Authentication=== | ===Authentication=== | ||
[[File:Passwordless_Web_Authentication.svg|thumb|right|A typical Web Authentication (WebAuthn) flow]] | [[File:Passwordless_Web_Authentication.svg|class=skin-invert-image|thumb|upright=1.2|right|A typical Web Authentication (WebAuthn) flow]] | ||
[[File:Android Credential Manager Conditional UI on Android screenshot (cropped).webp|thumb|upright=1.2|Example of WebAuthn authentication with Android Credential Manager]] | |||
Authenticator is a multi-factor [[Cryptography|cryptographic]] authenticator that uses [[Cryptography#Public-key cryptography|public-key cryptography]] to sign an authentication assertion targeted at the website. Assuming the authenticator uses either a [[Facial recognition system|facial recognition]], fingerprint or PIN for user verification, the authenticator itself is ''something you have'' while the facial recognition and fingerprint (biometric) are ''something you are'' and the PIN is ''something you know''. | |||
To initiate the | To initiate the authentication flow, the website indicates its intentions to the web browser via [[JavaScript]].<ref name="Web_Authentication_API-1">{{cite web |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |title=Web Authentication API |at=Section [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API#Authentication Authentication] |publisher=[[Mozilla]] |access-date=18 March 2019 |archive-date=28 November 2020 |archive-url=https://web.archive.org/web/20201128172824/https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |url-status=live }}</ref> The web browser communicates with the authenticator using a JavaScript [[API]] implemented in the browser.<ref name="Web_Authentication_API-1" /><ref name="W3C-WebAuthn-Level-1" /> A hardware authenticator in the user's possession conforms to the FIDO [[Client to Authenticator Protocol]] (CTAP),<ref name="FIDO-CTAP">{{cite web |editor1-last=Brand |editor1-first=Christiaan |editor2-last=Czeskis |editor2-first=Alexei |editor3-last=Ehrensvärd |editor3-first=Jakob |editor4-last=Jones |editor4-first=Michael B. |editor5-last=Kumar |editor5-first=Akshay |editor6-last=Lindemann |editor6-first=Rolf |editor7-last=Powers |editor7-first=Adam |editor8-last=Verrept |editor8-first=Johan |title=Client to Authenticator Protocol (CTAP) |url=https://fidoalliance.org/specs/fido-v2.0-ps-20190130-pub/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html |publisher=FIDO Alliance |access-date=7 March 2019 |date=30 January 2019 |archive-date=8 March 2019 |archive-url=https://web.archive.org/web/20190308081859/https://fidoalliance.org/specs/fido-v2.0-ps-20190130-pub/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html |url-status=dead }}</ref> and connects over [[USB]], [[Bluetooth Low Energy]], or [[near-field communications]] (NFC). WebAuthn however does not strictly require a hardware authenticator. A platform authenticator (i.e., an authenticator implemented directly on the web browser or operating system) can be used.<ref>{{Cite journal |last1=Vasileios Grammatopoulos |first1=Athanasios |last2=Politis |first2=Ilias |last3=Xenakis |first3=Christos |date=2021-08-17 |title=A web tool for analyzing FIDO2/WebAuthn Requests and Responses |url=https://dl.acm.org/doi/10.1145/3465481.3469209 |journal=Proceedings of the 16th International Conference on Availability, Reliability and Security |language=en |publisher=ACM |pages=1–10 |doi=10.1145/3465481.3469209 |isbn=978-1-4503-9051-4}}</ref> If the user has registered their keys on a different device the WebAuthn 3 specification allows for the web browser to access credentials stored on another device without having to copy over the keys to the current device. | ||
===Registration=== | |||
When the website receives the signed authentication assertion from the browser, the digital signature on the assertion is verified using a trusted public key for the user. | |||
===Registration=== | To obtain a public key for the user, the website initiates a WebAuthn registration flow<ref>{{cite web |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |title=Web Authentication API |at=Section [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API#Registration Registration] |publisher=[[Mozilla]] |access-date=18 March 2019 |archive-date=28 November 2020 |archive-url=https://web.archive.org/web/20201128172824/https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |url-status=live }}</ref> that is similar to the authentication flow illustrated above. The primary difference is that the authenticator now signs an attestation statement with its attestation private key. The signed attestation statement contains a copy of the public key that the website ultimately uses to verify a signed authentication assertion. The attestation certificate contains metadata describing the authenticator itself.<ref>{{Cite web |date=2025-05-28 |title=Attestation and Assertion - Web APIs |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion |access-date=2025-09-20 |website=[[MDN Web Docs]] |language=en-US}}</ref> | ||
The digital signature on the attestation statement is verified with the trusted attestation public key for that particular model of authenticator. How the website obtains its store of trusted attestation public keys is unspecified. One option is to use the FIDO metadata service.<ref>{{cite web |title=Metadata Service |date=15 September 2015 |url=https://fidoalliance.org/metadata/ |publisher=[[FIDO Alliance]] |access-date=18 March 2019}}</ref> | |||
The attestation type specified in the JavaScript determines the trust model. For instance, an attestation type called self-attestation may be desired, for which the trust model is essentially [[trust on first use]]. | |||
=== Level 3 === | |||
The | WebAuthn Level 3 introduces several capabilities beyond authentication alone. The PRF (Pseudo-Random Function) extension allows a passkey to derive encryption keys, enabling it to help protect encrypted data such as backups without a separate password.<ref name="enpass-webauthn3">{{Cite web |title=What Is WebAuthn Level 3 & How Does Enpass Support It? |url=https://www.enpass.io/blog/security/what-is-webauthn-level-3-how-does-enpass-support-it/ |publisher=Enpass |date=23 July 2026 |access-date=20 August 2026}}</ref> Related Origin Requests (ROR) let a single passkey be used across multiple domains belonging to the same organization, reducing the need for duplicate credentials.<ref name="enpass-webauthn3" /> The specification also added a section addressing the privacy implications of using WebAuthn credentials across origins, including risks associated with cross-origin iframes.<ref>{{Cite web |title=[L3 REC] Transition Request Draft |url=https://github.com/w3c/webauthn/issues/2399 |publisher=GitHub |website=w3c/webauthn |access-date=20 August 2026}}</ref> | ||
== Support == | == Support == | ||
[[File:Bitwarden | [[File:Bitwarden Desktop 2025.7.0 with passkey support screenshot.webp|thumb|upright=1.2|Example of WebAuthn passkey as a part of password manager [[Bitwarden]]]] | ||
The WebAuthn Level 1 standard was published as a W3C Recommendation by the [[Web Authentication Working Group]] on 4 March 2019.<ref name="W3C-WebAuthn-Level-1" /><ref name="W3C-WebAuthn-announce" /><ref>{{Cite web |url=https://venturebeat.com/2019/03/04/w3c-approves-webauthn-as-the-web-standard-for-password-free-logins/ |title=W3C Approves WebAuthn as the Web Standard for Password-Free Logins |last=Protalinski |first=Emil |date=4 March 2019}}</ref> WebAuthn is supported by [[Google Chrome]], [[Mozilla Firefox]], [[Microsoft Edge]], [[Safari (web browser)|Apple Safari]]<ref name="W3C-WebAuthn-announce" /> and [[Opera (web browser)|Opera]].<ref>{{cite web |title=Can I use Web Authentication API? |url=https://caniuse.com/#feat=webauthn |access-date=7 March 2019}}</ref> | |||
The WebAuthn Level 1 standard was published as a W3C Recommendation by the [[Web Authentication Working Group]] on 4 March 2019.<ref name="W3C-WebAuthn-Level-1" /><ref name="W3C-WebAuthn-announce" /><ref>{{Cite web |url=https://venturebeat.com/2019/03/04/w3c-approves-webauthn-as-the-web-standard-for-password-free-logins/ |title=W3C Approves WebAuthn as the Web Standard for Password-Free Logins |last=Protalinski |first=Emil |work=VentureBeat |date=4 March 2019 |access-date=4 March 2019 |archive-date=4 March 2019 |archive-url=https://web.archive.org/web/20190304160032/https://venturebeat.com/2019/03/04/w3c-approves-webauthn-as-the-web-standard-for-password-free-logins/ |url-status=live }}</ref> WebAuthn is supported by [[Google Chrome]], [[Mozilla Firefox]], [[Microsoft Edge]], [[Safari (web browser)|Apple Safari]]<ref name="W3C-WebAuthn-announce" /> and [[Opera (web browser)|Opera]].<ref>{{cite web |title=Can I use Web Authentication API? |url=https://caniuse.com/#feat=webauthn |access-date=7 March 2019 |archive-date=19 February 2018 |archive-url=https://web.archive.org/web/20180219074228/https://caniuse.com/#feat=webauthn |url-status=live }}</ref> | |||
The desktop version of Google Chrome has supported WebAuthn since version 67.<ref name="chrome-support">{{cite web |url=https://developers.google.com/web/updates/2018/05/webauthn |title=Enabling Strong Authentication with WebAuthn |first=Christiaan |last=Brand |website=Google Developers |date=2018-06-03 |access-date=2018-06-25}}</ref> Firefox, which had not fully supported the previous FIDO U2F standard, included and enabled WebAuthn in Firefox version 60, released on 9 May 2018.<ref>{{cite web |url=https://www.cnet.com/news/firefox-moves-browsers-into-the-post-password-future-with-webauthn/ |title=Firefox moves browsers into post-password future with WebAuthn tech |first=Stephen |last=Shankland |website=CNET |date=2018-05-09 |access-date=2018-05-11}}</ref> An early [[Windows Insider]] release of Microsoft Edge (Build 17682) implemented a version of WebAuthn that works with both [[Windows Hello]] as well as external security keys.<ref>{{cite web |url=https://blogs.windows.com/windowsexperience/2018/05/31/announcing-windows-10-insider-preview-build-17682/#oHYCS0GkF95OMzKH.97 |title=Announcing Windows 10 Insider Preview Build 17682 |author=Sarkar |display-authors=etal |publisher=Microsoft |date=2018-05-23 |access-date=2018-06-25}}</ref> | The desktop version of Google Chrome has supported WebAuthn since version 67.<ref name="chrome-support">{{cite web |url=https://developers.google.com/web/updates/2018/05/webauthn |title=Enabling Strong Authentication with WebAuthn |first=Christiaan |last=Brand |website=Google Developers |date=2018-06-03 |access-date=2018-06-25 |archive-date=4 September 2018 |archive-url=https://web.archive.org/web/20180904204546/https://developers.google.com/web/updates/2018/05/webauthn |url-status=live }}</ref> Firefox, which had not fully supported the previous FIDO U2F standard, included and enabled WebAuthn in Firefox version 60, released on 9 May 2018.<ref>{{cite web |url=https://www.cnet.com/news/firefox-moves-browsers-into-the-post-password-future-with-webauthn/ |title=Firefox moves browsers into post-password future with WebAuthn tech |first=Stephen |last=Shankland |website=CNET |date=2018-05-09 |access-date=2018-05-11 |archive-date=12 May 2018 |archive-url=https://web.archive.org/web/20180512112654/https://www.cnet.com/news/firefox-moves-browsers-into-the-post-password-future-with-webauthn/ |url-status=live }}</ref> An early [[Windows Insider]] release of Microsoft Edge (Build 17682) implemented a version of WebAuthn that works with both [[Windows Hello]] as well as external security keys.<ref>{{cite web |url=https://blogs.windows.com/windowsexperience/2018/05/31/announcing-windows-10-insider-preview-build-17682/#oHYCS0GkF95OMzKH.97 |title=Announcing Windows 10 Insider Preview Build 17682 |author=Sarkar |display-authors=etal |publisher=Microsoft |date=2018-05-23 |access-date=2018-06-25 |archive-date=7 April 2019 |archive-url=https://web.archive.org/web/20190407194514/https://blogs.windows.com/windowsexperience/2018/05/31/announcing-windows-10-insider-preview-build-17682/#oHYCS0GkF95OMzKH.97 |url-status=live }}</ref> | ||
Existing FIDO U2F security keys are largely compatible with the WebAuthn standard, though WebAuthn added the ability to reference a unique per-account "user handle" identifier, which older authenticators are unable to store.<ref name="W3C-WebAuthn-Level-1" /> | Existing FIDO U2F security keys are largely compatible with the WebAuthn standard, though WebAuthn added the ability to reference a unique per-account "user handle" identifier, which older authenticators are unable to store.<ref name="W3C-WebAuthn-Level-1" /> | ||
One of the first FIDO2-compatible [[authenticator]]s was the second-generation [[YubiKey|Security Key]] by Yubico, announced on 10 April 2018.<ref>{{cite press release |url=https://www.yubico.com/press-releases/280530/ |title=Yubico Launches New Developer Program and Security Key for FIDO2 and WebAuthn W3C Specifications |date=2018-04-10 |access-date=2018-05-11}}</ref> The first FIDO2-compatible | One of the first FIDO2-compatible [[authenticator]]s was the second-generation [[YubiKey|Security Key]] by Yubico, announced on 10 April 2018.<ref>{{cite press release |url=https://www.yubico.com/press-releases/280530/ |title=Yubico Launches New Developer Program and Security Key for FIDO2 and WebAuthn W3C Specifications |date=2018-04-10 |access-date=2018-05-11 |archive-date=7 May 2018 |archive-url=https://web.archive.org/web/20180507085439/https://www.yubico.com/press-releases/280530/ |url-status=live }}</ref> The first FIDO2-compatible authenticator with a display was Trezor Model T by SatoshiLabs, announced on 6 November 2019.<ref>{{cite web |url=https://medium.com/trezor-security-blog/make-passwords-a-thing-of-the-past-a402745750dc |title=Make Passwords a Thing of the Past, FIDO2 Is Now Available on Trezor Model T |date=2019-11-06 |access-date=2019-11-06}}</ref> Trezor Model T was also the first authenticator that allowed users to select which FIDO2 resident credential should be used directly on a device. | ||
The first Security Level 2 certified FIDO2 key, called "Goldengate" was announced one year later by eWBM on 8 April 2019.<ref>{{cite press release |url=https://www.ewbm.com/press/pr2/ |title=eWBM: eWBM's Goldengate Fingerprint Reader is First to Get FIDO L2 Certification |date=2019-04-08 |access-date=2019-06-15 |archive-date=1 January 2020 |archive-url=https://web.archive.org/web/20200101151355/https://www.ewbm.com/press/pr2/ |url-status=dead }}</ref><ref>{{cite press release |url=https://mobileidworld.com/ewbm-goldengate-fingerprint-reader-fido-l2-certification-804084/ |title=Mobile ID World, Alex Perala: eWBM's Goldengate Fingerprint Reader is First to Get FIDO L2 Certification |date=2019-04-09 |access-date=2019-06-15}}</ref> | The first Security Level 2 certified FIDO2 key, called "Goldengate" was announced one year later by eWBM on 8 April 2019.<ref>{{cite press release |url=https://www.ewbm.com/press/pr2/ |title=eWBM: eWBM's Goldengate Fingerprint Reader is First to Get FIDO L2 Certification |date=2019-04-08 |access-date=2019-06-15 |archive-date=1 January 2020 |archive-url=https://web.archive.org/web/20200101151355/https://www.ewbm.com/press/pr2/ |url-status=dead }}</ref><ref>{{cite press release |url=https://mobileidworld.com/ewbm-goldengate-fingerprint-reader-fido-l2-certification-804084/ |title=Mobile ID World, Alex Perala: eWBM's Goldengate Fingerprint Reader is First to Get FIDO L2 Certification |date=2019-04-09 |access-date=2019-06-15 |archive-date=12 August 2020 |archive-url=https://web.archive.org/web/20200812130916/https://mobileidworld.com/ewbm-goldengate-fingerprint-reader-fido-l2-certification-804084/ |url-status=live }}</ref> | ||
[[Dropbox]] announced support for WebAuthn logins (as a 2nd factor) on 8 May 2018.<ref>{{cite web |url=https://blogs.dropbox.com/tech/2018/05/introducing-webauthn-support-for-secure-dropbox-sign-in/ |title=Introducing WebAuthn support for secure Dropbox sign in |first=Brad |last=Girardeau |publisher=Dropbox |work=Dropbox Tech Blog |date=2018-05-08 |access-date=2018-05-11}}</ref> | [[Dropbox]] announced support for WebAuthn logins (as a 2nd factor) on 8 May 2018.<ref>{{cite web |url=https://blogs.dropbox.com/tech/2018/05/introducing-webauthn-support-for-secure-dropbox-sign-in/ |title=Introducing WebAuthn support for secure Dropbox sign in |first=Brad |last=Girardeau |publisher=Dropbox |work=Dropbox Tech Blog |date=2018-05-08 |access-date=2018-05-11 |archive-date=12 May 2018 |archive-url=https://web.archive.org/web/20180512112811/https://blogs.dropbox.com/tech/2018/05/introducing-webauthn-support-for-secure-dropbox-sign-in/ |url-status=live }}</ref> | ||
[[Apple Inc.|Apple]] announced that [[Face ID]] or [[Touch ID]] could be used as a WebAuthn platform authenticator with [[Safari (web browser)|Safari]] on 24 June 2020.<ref>{{Cite web |date=2022-12-16 |title=Safari 14 Release Notes |url=https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes |access-date=2022-12-16 |website=Apple Developer Documentation}}</ref> | [[Apple Inc.|Apple]] announced that [[Face ID]] or [[Touch ID]] could be used as a WebAuthn platform authenticator with [[Safari (web browser)|Safari]] on 24 June 2020.<ref>{{Cite web |date=2022-12-16 |title=Safari 14 Release Notes |url=https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes |access-date=2022-12-16 |website=Apple Developer Documentation |archive-date=14 May 2021 |archive-url=https://web.archive.org/web/20210514183054/https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes |url-status=live }}</ref> | ||
Several [[ | Several [[password manager]]s such as [[Bitwarden]] and [[Dashlane]] support WebAuthn.<ref>{{Cite web |last=Porter |first=Jon |date=2023-11-02 |title=Bitwarden begins adding passkey support to its password manager |url=https://www.theverge.com/2023/11/2/23943173/bitwarden-passkey-support-released-browser-extension |access-date=2025-08-12 |website=[[The Verge]] |language=en-US |archive-date=17 July 2025 |archive-url=https://web.archive.org/web/20250717030741/https://www.theverge.com/2023/11/2/23943173/bitwarden-passkey-support-released-browser-extension |url-status=live }}</ref><ref>{{Cite web |last=Pegoraro |first=Rob |date=2024-07-30 |title=These Are the Services Seeing the Biggest Uptick in Passkey Adoption |url=https://uk.pcmag.com/password-managers/153627/these-are-the-services-seeing-the-biggest-uptick-in-passkey-adoption |access-date=2025-08-12 |website=[[PC Magazine]] UK |language=en-gb |archive-date=8 November 2024 |archive-url=https://web.archive.org/web/20241108214849/https://uk.pcmag.com/password-managers/153627/these-are-the-services-seeing-the-biggest-uptick-in-passkey-adoption |url-status=live }}</ref> | ||
== API == | == API == | ||
WebAuthn implements an extension of the W3C's more general [[Credential Management]] [[application programming interface|API]], which is an attempt to formalize the interaction between [[website]]s and [[web browser]]s when exchanging user credentials. The Web Authentication API<ref>{{cite web |title=Web Authentication API |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |publisher=[[Mozilla]] |access-date=16 March 2019}}</ref><ref>{{cite web |last1=Ackermann |first1=Yuriy |title=Introduction to WebAuthn API |url=https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285 |publisher=Medium |access-date=8 March 2019 |date=15 January 2019}}</ref> extends the Credential Management <code>navigator.credentials.create()</code> and <code>navigator.credentials.get()</code> [[JavaScript]] methods so they accept a <code>publicKey</code> parameter. The <code>create()</code> method is used for registering public key [[authenticator]]s as part of associating them with user accounts (possibly at initial account creation time but more likely when adding a new security device to an existing account) while the <code>get()</code> method is used for authenticating (such as when logging in). | WebAuthn implements an extension of the W3C's more general [[Credential Management]] [[application programming interface|API]], which is an attempt to formalize the interaction between [[website]]s and [[web browser]]s when exchanging user credentials. The Web Authentication API<ref>{{cite web |title=Web Authentication API |url=https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |publisher=[[Mozilla]] |access-date=16 March 2019 |archive-date=28 November 2020 |archive-url=https://web.archive.org/web/20201128172824/https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API |url-status=live }}</ref><ref>{{cite web |last1=Ackermann |first1=Yuriy |title=Introduction to WebAuthn API |url=https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285 |publisher=Medium |access-date=8 March 2019 |date=15 January 2019 |archive-date=29 March 2019 |archive-url=https://web.archive.org/web/20190329183504/https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285 |url-status=live }}</ref> extends the Credential Management <code>navigator.credentials.create()</code> and <code>navigator.credentials.get()</code> [[JavaScript]] methods so they accept a <code>publicKey</code> parameter. The <code>create()</code> method is used for registering public key [[authenticator]]s as part of associating them with user accounts (possibly at initial account creation time but more likely when adding a new security device to an existing account) while the <code>get()</code> method is used for authenticating (such as when logging in). | ||
To check if a browser supports WebAuthn, scripts should check if the <code>window.PublicKeyCredential</code> interface is defined. In addition to <code>PublicKeyCredential</code>, the standard also defines the <code>AuthenticatorResponse</code>, <code>AuthenticatorAttestationResponse</code>, and <code>AuthenticatorAssertionResponse</code> interfaces in addition to a variety of dictionaries and other datatypes. | To check if a browser supports WebAuthn, scripts should check if the <code>window.PublicKeyCredential</code> interface is defined. In addition to <code>PublicKeyCredential</code>, the standard also defines the <code>AuthenticatorResponse</code>, <code>AuthenticatorAttestationResponse</code>, and <code>AuthenticatorAssertionResponse</code> interfaces in addition to a variety of dictionaries and other datatypes. | ||
The API does not allow direct access to or manipulation of private keys, beyond requesting their initial creation. | The API does not allow direct access to or manipulation of private keys, beyond requesting their initial creation. | ||
== Reception == | == Reception == | ||
In August 2018, Paragon Initiative Enterprises conducted a security audit of the WebAuthn standard. While they could not find any specific [[Exploit (computer security)|exploits]], they revealed some serious weaknesses in the way the underlying cryptography is used and mandated by the standard.<ref name="paragon-blog">{{cite web|url=https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet|title=Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)|publisher=Paragon Initiative Enterprises Blog|date=2018-08-23|access-date=2018-10-09}}</ref> | In August 2018, Paragon Initiative Enterprises conducted a security audit of the WebAuthn standard. While they could not find any specific [[Exploit (computer security)|exploits]], they revealed some serious weaknesses in the way the underlying cryptography is used and mandated by the standard.<ref name="paragon-blog">{{cite web|url=https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet|title=Security Concerns Surrounding WebAuthn: Don't Implement ECDAA (Yet)|publisher=Paragon Initiative Enterprises Blog|date=2018-08-23|access-date=2018-10-09|archive-date=10 October 2018|archive-url=https://web.archive.org/web/20181010011257/https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet|url-status=live}}</ref> | ||
Main points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past, and therefore should be avoided in order to not fall victim to the same class of attacks: | Main points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past, and therefore should be avoided in order to not fall victim to the same class of attacks: | ||
| Line 162: | Line 136: | ||
ECDAA was only designed to use in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.<ref>{{Cite web|date=2020-04-28|title=Remove ECDAA? · Issue #1410 · w3c/webauthn|url=https://github.com/w3c/webauthn/issues/1410|access-date=2020-06-03|website=GitHub|language=en}}</ref> | ECDAA was only designed to use in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.<ref>{{Cite web|date=2020-04-28|title=Remove ECDAA? · Issue #1410 · w3c/webauthn|url=https://github.com/w3c/webauthn/issues/1410|access-date=2020-06-03|website=GitHub|language=en}}</ref> | ||
== See also == | == See also == | ||
| Line 179: | Line 142: | ||
== References == | == References == | ||
{{reflist}} | {{reflist}} | ||