A passkey is a way to use Web Authentication (WebAuthn), the standard powering the next generation of signing in on the web. Unlike passwords, passkeys are cryptographic key pairs (just like SSL/TLS uses) that are never reused, bound to the site they're created for, and typically protected by device biometrics (such as a fingerprint or facial scan).

This means that phishing and lost credentials are effectively a thing of the past. Services using WebAuthn store only public keys, meaning that if there was a system breach, the sign in data would be useless to malicious actors. Servers never get access to any sensitive information.

Seriously. Here's one of our public keys (P-256):

x: 9717D82451A62EC979D3E1C48BF39D5A814B46725157D2EABDF214FB62828E34
y: 3F2D59CF9F6FC682D93ED4FE2BC18B6206E67A1740FEF15F81BB1B971331CDA9

No.

Passkeys, and the WebAuthn standard that powers them, send only a cryptographic public key to the website during registration (and, optionally, some information about the device type, such as the manufacturer). Biometric data never leaves your device.

Passkeys do not relay any personal information about you to the sites that use them.

WebAuthn is based around public key authentication. Here's the express version:

During registration, the browser gets a Challenge to cryptographically sign from the server. WebAuthn APIs then ask the system to use a cryptographic keypair, tied to the site domain, to sign the Challenge. For passkeys, this keypair is generated on the fly and stored securely by the operating system. If using a hardware device (such as a YubiKey), the internals are a little different but the private key never leaves the device; the public key is provided to the WebAuthn APIs. The signature is then sent to the server along with the public key to the server for verification and storage.

When signing in, the browser again requests a Challenge from the server, along with (optionally) a list of key identifiers that are associated with the user trying to sign in. The Challenge is then signed on-device using the previously-generated private key and the signature is sent back to the server. The server looks up the previously-registered public key(s) for the user, cryptographically verifies the signature, and if everything checks out, let's the user proceed!

There's a pretty neat two-minute video at https://webauthn.guide (not affiliated).

As little as possible: we take privacy very seriously, and consider personal information to be a liability. We have no interest in tracking you or your users - either on our site or yours. We collect no data not explicitly provided to us by you, and credentials contain no PII.

We retain authentication timestamps for a limited amount of time for billing purposes.

See our privacy policy for more details.

Absolutely nothing from end users.

We use Stripe for billing, and share a billing email with them, in addition to what you provide to set up a payment method.

We also collect anonymous operational telemetry to monitor the service and keep it healthy. It contains no user data.

See our privacy policy for more details.

NO! We 🤬 hate it when companies do this, and are willing to bet you do too.

We will only use your email address for important account information, like payment notifications.

If, in the future we even have a mailing list, we may send you a single email to let you know it exists. Otherwise it will be opt-in.

A Monthly Active User (MAU) is a User Account that signs in to your service during a given billing period. See pricing for details.

No, and you can use the free trial as long as you want. However we do require a credit card to go past the free user limit. Paid plans are usage-based and have a $5/month minimum— see our pricing page for details. Stripe may put a temporary authorization on your card when you set it up to validate it.

Yes, but we don't have SDKs yet. They're coming soon. If you're determined, the JS API is pretty simple. Heck, if you help build the SDK for a new platform, we'll give you additional free users.

The spec is about 250 pages long, requires you to implement several different data formats, and necessitates use of error-prone cryptographic operations. Even with a library to help out, there's a lot to manage server-side, browser bugs to contend with, hundreds of combinations of request options, and more.

Having to do all of this is what prompted us to create a hosted offering.

But at the end of the day, we want to see the web become more secure, with our without our help. If managing your own Relying Party server is more your speed, great! That's still one more application more secure than using passwords.

Nothing immediately - we understand that stuff happens and payments can fail for all sorts of reasons, and it would be Really Not Cool™ if your app broke if this happened. We'll email you to get it corrected, and send regular reminders. Additionally, our APIs will return a warning indicating that an action is required — they'll continue to work normally.

If after a full billing cycle payments are still behind, registration APIs will start returning 402 Payment Required. Authentication will not be impacted.

If after a second billing cycle payments are still past due, authentication APIs will also start returning 402 errors.

At no point will we disable access to the dashboard.

If you have extenuating circumstances, please contact us and we will do our best to accommodate you.

Yup.

We hope you find it so easy and reliable to use that you also add it to your main website.

While we intend to be around for the long haul and stay independently operated, plans could change. We've designed the service from the ground up with this possibility in mind, so that you can be confident that your auth system stays up. To this end, we've:

• Set up the WebAuthn flows to run from your domain, using your Relying Party ID
• Stored data using standard formats whenever possible
• Prepared a data export system¹
• Built on top of open-source software, and contribute back upstream

By default, you'll get a one-factor authentication (proof-of-possession). We're working to expand configuration of this situation.