What passkeys are
A passkey is a sign-in credential based on the FIDO standards: a key pair made for one account on one service. The service keeps only the public key. The private key stays with the person, on their phone, computer, password manager or security key, and they approve each use the way they open their device: with a fingerprint, their face or a PIN.
Passkeys rest on WebAuthn, the browser standard published by the W3C, and CTAP, the FIDO Alliance's protocol for authenticators. They are supported in all major operating systems and browsers, and a passkey is only presented to the site or app it was made for, which makes it resistant to phishing. That is why passkeys are at the centre of sign-in in our authentication module.
What it does in your platform
Authentication
Lets customers sign in with a passkey instead of a password, and use it again as the second factor when they confirm a payment. Passkeys can replace passwords entirely, with one-time codes as a fallback on devices that do not support them.
How the connection works
Passkeys need no outside service. The module is the relying party, the service the passkeys belong to; browsers speak WebAuthn, and phones use the passkey support built into iOS and Android.
The customer makes one
After sign-up, the app offers a passkey. The phone creates a key pair for your service only and asks for Face ID, a fingerprint or the PIN.
The public key is saved
The phone sends the public key to the module, which stores it against the customer. The private key stays on the phone, or in the password manager that syncs it between the customer's devices.
Signing in
Next time, the module sends a fresh challenge. The customer approves on the phone, which signs it with the private key, and the module checks the signature against the stored public key.
Confirming a payment
A transfer or a card payment asks for the passkey again before it goes ahead, as the second factor strong customer authentication requires.
A new phone
Synced passkeys follow the customer to a new phone through their password manager. Device-bound ones stay behind, and the module's recovery flow lets the customer back in without calling support.
Next to other factors
Passkeys sit next to the module's other second factors: authenticator apps, one-time codes through Twilio Verify and push approval in your own app. Customers whose devices cannot use a passkey fall back to one-time codes, so nobody is locked out.
Passkeys also work under the identity providers we connect to: Keycloak and AWS Cognito, for example, support them as a sign-in method. Where the provider holds the passkeys, the module still keeps the sessions and the payment confirmation.
When passkeys fit best
A strong fit when
- You want customers to stop using passwords, and stop losing accounts to phishing.
- Your customers use current phones and browsers, where passkey support is built in.
- You want one gesture for signing in and for confirming payments.
Also worth a look
- One-time codes by app, SMS or email, for devices without passkey support.
- Push approval in your own app, for customers who prefer to approve a request on their phone.
How we get you live
Your domains
We set your domains up as the passkeys' relying party and link your apps to them, so the same passkey works in your app and on your website.
The rules
We decide with you when a passkey is offered, when it is required, and which fallback applies on devices without one.
The keys
The platform stores only public keys, so its database holds nothing a thief could sign in with. There is no provider secret to manage.
A full test run
We test making, using and recovering passkeys on iPhone, Android and the main browsers before your customers see them.
