Better Security Using the Web Authentication API
Your processor said passkeys. Your platform says WebAuthn. Your developer says FIDO2. Are those three different things? Or just one? And does your checkout need any of them?
The problem is that passwords are not particularly secure. Customers forget passwords, and fraudsters can buy them. Verizon’s 2026 Data Breach Investigations Report puts credential abuse at 13% of breaches as the first point of entry. Only vulnerability exploitation, at 31%, ranks higher.
Web Authentication presents a potential solution to this problem.
In this post, I’ll take you through what Web Authentication is, how it works, what the card networks are doing with it, and what to check first.
Recommended reading
- What is Alipay? Can US Consumers & Merchants Use Alipay?
- Terminal ID Number (TID): What is it? What Does it Do?
- Shortened Descriptors: How to Optimize Your Static Prefix
- Subscription Chargebacks & Optimizing Payment Infrastructure
- Agentic Commerce Is Coming. Who Owns the Consequences?
- What Are Credit Card Networks? What Do Card Networks Do?
What Is Web Authentication?
- Web Authentication
Web Authentication API is a credential management API developed by the World Wide Web Consortium (W3C). This standard lets web applications authenticate users without storing their passwords on servers.
[noun]/web • ô • then • tǝ • kā • shǝn/
Online user authentication problems have existed almost as long as the web itself. The most common solution to date has been based on the assumption that only the user has access to their username and password. If both match, the site assumes the user is legitimate.
Passwords are easily stolen, though, especially when reused by customers for multiple platforms. And while the username and password method probably won’t disappear completely, a better customer verification method is needed. That brings us to Web Authentication, or WebAuthn.
WebAuthn is an Application Programming Interface (API) that lets applications verify users’ identities without accessing or storing their passwords. The API does what passwords are supposed to do… but it does it more effectively.
WebAuthn, FIDO2, or Passkeys: Which Is It?
WebAuthn, FIDO2, and passkeys: all three are components of the same process. They’re closely related, but not exactly the same thing.
In practical terms, your platform documentation will say WebAuthn. Your customers will see “Sign in with a passkey.” That is the primary difference.
WebAuthn
The W3C standard. This is the part that runs in the browser and gives your website a way to ask the browser for a signed proof of identity instead of a password.
FIDO2
The FIDO Alliance’s name for WebAuthn plus CTAP. CTAP is the protocol that lets the browser talk to a security key or to the phone’s own secure hardware. In simple terms, FIDO2 is WebAuthn plus the standard that talks to the device. When a vendor says FIDO2, they mean the full stack.
Passkey
The credential itself that WebAuthn and FIDO2 produce together. The FIDO Alliance specifies it’s a credential “that allows a user to sign in to apps and websites with the same process that they use to unlock their device.” It’s the word your customers will see on screen; Apple, Google, and Microsoft all use this word on their sign-in screens.
What Is Public Key Authentication?
Web Authentication API was developed by the World Wide Web Consortium (W3C) in association with the FIDO (Fast IDentity Online) Alliance. The goal was to standardize simpler and stronger login credentials through public-key authentication, rather than a password.
Public-key authentication uses a pair of keys instead of a single password. These keys are not something that a fraudster can simply “guess;” they’re a cryptographic key pair, generated on the customer’s device, and the two halves are mathematically linked. One is a public key that can be shared with a server, but the other is a private key solely stored with the user.
The private key simply verifies that the person seeking access is the real user. It doesn’t give any information about the user. It only confirms that the user is legitimate.
The public key is not “public” in the sense that there is a published list somewhere. It’s just the only part of the equation outside sites can access. It doesn’t have to be secret because the public one is effectively useless without the corresponding private key.
Put another way: even if hackers breached an extensive database full of user credentials, all they would get is a list of meaningless numbers. Each public key is bound to one private key. There’s no practical way to work out the private key from the public one.
How Does Web Authentication Work?
Public-key cryptography is one of the common factors of all FIDO authenticators. There are three components to this process:
The most important thing to note is that the authenticator’s connection to the client does not happen online. The information passed between the client, and the authenticator is at no point accessible to any outside source or interference.
Synced & Device-Bound Passkeys
The authenticator is where the private key lives. Since 2022, there have been two ways to keep it there.
A device-bound passkey never leaves the hardware it was created on. A hardware security key holds one. So does a phone with syncing turned off. If you lose the device, then the passkey is gone.
A synced passkey is backed up, end-to-end encrypted, through the platform’s own account: iCloud Keychain on Apple devices, Google Password Manager on Android and Chrome. A customer who creates one on their phone can use it on their laptop, and a replacement phone gets it back. The FIDO Alliance uses these two terms, and your platform documentation will, too.
| Synced passkey | Device-bound passkey | |
| Where the private key lives | On the device, backed up to the platform account | On one device only |
| Customer loses the phone | Restores with the account on the new phone | Passkey is gone, customer re-enrolls |
| Typical authenticator | Phone, laptop, password manager | Hardware security key, un-synced device |
| Common for customer logins | Yes | Rare |
It’s worth checking which kind your platform issues. For a consumer login, synced is the one that keeps support tickets down.
The Web Authentication Security Process
There are two different stages of the secure Web Authentication process:
How a passkey sign-in works
Registered Once. Proven Every Time.
The private key never leaves the customer’s device. Your site only ever holds the public key, and checks every sign-in against it.
- Your SiteRelying party
- BrowserWebAuthn client
- Customer’s DeviceAuthenticator
01RegistrationOnce per device
Face, fingerprint or PIN
Private key stays here
Public key saved
02Sign-inEvery time
Face, fingerprint or PIN
Signed with the private key
Signature checked.
Customer signed in.
03Look-alike sitePhishing attempt
No passkey for this domain.
Nothing signed.
In a nutshell: the user attempts to sign in, and the site asks the browser for proof of the user’s identity. In turn, the browser requests that information from the Authenticator. As we mentioned above, this evidence could be a physical security key, a fingerprint sensor, etc.
When the Authenticator confirms the user’s identity, it passes that information back to the browser, forwarding it to the site. It either gives the site permission to accept the user’s login or rejects it in case of a mismatch.
While the process is obviously more involved, those are the basic steps. Essentially, the Authenticator is a go-between that’s trusted by both sides. This allows the browser to accept the evidence without accessing the data itself. All the action takes place behind the scenes and happens almost instantly.
What Advantages Does WebAuthn Offer?
This new technology is considered the best validation technique available. It raises the bar for protecting user accounts. In doing so, WebAuthn offers benefits for both users and merchants.
Consumer Convenience
Customers love convenience. Most customers won’t have to install specific software to use WebAuthn security. The framework was developed in conjunction with Google, Mozilla, Microsoft, and others. With so many major players involved, users will find that everything they need is built into what they are already using.
Custom Configurations
WebAuthn allows for single-factor, two-factor, or multi-factor authentication. Merchants can even provide an additional layer of identity verification for specific in-app actions, such as changing passwords.
While it’s possible to allow user access based simply on WebAuthn verification, sites can also require a secondary method to ensure robust customer authentication compliance.
Tighter Security
WebAuthn doesn’t just create one pair of cryptographic keys. Instead, it makes unique keys for each website. In the unlikely event that a third party managed to gain access to a user account, that information would not allow them to access any other account.
The private user key is only stored on the user’s device. For consumers, this helps eliminate the threats of credential theft and phishing. At the same time, merchants are protected from potential liability following a data breach, as they are no longer storing customers’ personal data.
The credential is tied to your domain. When the browser asks the authenticator to sign, it includes the relying party ID, which is your site’s domain. A look-alike domain gets a different ID, so the authenticator has no matching passkey and nothing to sign. The phishing page can be a perfect copy and it still gets nothing. That is what "phishing-resistant" means in the FIDO material.
Passkeys at Checkout: What Visa & Mastercard Are Doing
Both networks now run passkey programs for card payments. They work like a passkey login, pointed at the payment step instead of the account.
Visa Payment Passkey binds a passkey to the cardholder’s device after a one-time enrollment. At a participating merchant, the cardholder confirms the payment with a fingerprint, face, or device PIN. Visa describes it as replacing “passwords and SMS one-time codes.”
Mastercard Payment Passkey Service does the same job and launched in India in August 2024. Both are built to FIDO standards. Your checkout reaches them through the network’s or your PSP’s integration, not through your own login.
The connection to 3-D Secure is specific. Beginning with the launch of 3DS version 2.1, a merchant that authenticated the cardholder with FIDO before the transaction can pass that data inside the 3DS message. EMVCo’s guidance says the issuer can use it “as part of their risk evaluation,” which is what lets the issuer approve without a challenge. The specification allows it. In practice, whether your acquirer and 3DS server actually pass the FIDO data fields is the question to ask. Our article on how 3-D Secure works covers the challenge flow itself.
For European transactions, a passkey also lines up with the rule. The European Banking Authority’s 2019 opinion on the elements of strong customer authentication covers it; one passkey unlock may meet two of the three validation methods, thereby making it sufficient to meet SCA standards. Whether it counts for your transaction depends on how your PSP built the workflow.
Are There Disadvantages to Using WebAuthn?
There are no serious downsides to using Web Authentication. That said, the system is still not perfect.
The first problem is recovery. Say a customer loses the phone that holds their only passkey; nothing in the standard stops you from registering a new one. What stops you is that you now have to prove who they are without the credential you trusted. That is your recovery policy, not the API. The FIDO Alliance’s guidance is to have customers register more than one authenticator up front. If every one is lost, you can only fall back to your original identity checks. Synced passkeys make this issue rare, but they don’t make it go away.
The second problem is scope. WebAuthn secures the login. It does nothing about what a legitimate customer does after they’re in. A cardholder who buys, receives, and then disputes the charge — in other words, commits friendly fraud — might have used a valid passkey the whole way through.
Passkeys are one part of a complete fraud prevention strategy. They aren’t the strategy.
Three Things to Check With Your Platform
Most merchants don’t build WebAuthn. Your eCommerce platform, identity vendor, or PSP builds it, and you turn it on. So, here are three questions to help you sort out whether the integration is ready:
Before you change any settings, check what your login page actually offers to a customer on a new device with no saved credentials. That is the whole thing. Are you looking for a truly comprehensive fraud solution for your business? Chargebacks911® can help you develop and implement a strategy that includes comprehensive fraud prevention, account takeover defense, and maximized revenue recovery. Contact us today to learn how much you could be saving.
FAQs
What is passkey authentication?
A login built on the FIDO2 and WebAuthn standards. The customer’s device holds a private key and your site holds the matching public key. To sign in, the customer unlocks the device with a fingerprint, face, or PIN, and the device signs a challenge from your site. No password is typed or stored.
Is a passkey the same as WebAuthn?
Nearly. WebAuthn is the browser standard, FIDO2 is that standard plus the device-side protocol, and a passkey is the credential they produce. Your developer will say WebAuthn. Your customer will see “passkey.”
Does a passkey count as strong customer authentication?
It can supply two of the three SCA elements. The European Banking Authority’s 2019 opinion treats a device-bound key as possession and a biometric as inherence. Whether a given transaction counts depends on how your PSP and issuer built the flow, so confirm it with your PSP.
What happens when a customer loses the phone their passkey is on?
If the passkey was synced through Apple or Google, it comes back with the account on the new phone. If it was device-bound, it’s gone, and the customer goes through your recovery flow. The FIDO Alliance recommends registering more than one authenticator so recovery is rarely needed.
