Passkeys, when used with Auth0, don’t actually replace passwords; they augment them, providing a more secure and convenient login experience that bypasses traditional password entry entirely.
Let’s see passkeys in action. Imagine a user, Alice, who has registered her FIDO2 security key (like a YubiKey or her phone’s biometric scanner) with Auth0 for her account.
When Alice visits your application’s login page, instead of seeing a username/password form, she might see a button like "Sign in with Passkey" or "Continue with Biometrics."
Clicking this button triggers a browser-level WebAuthn API call. Auth0 orchestrates this by sending a challenge to the browser. The browser, in turn, prompts Alice’s device to authenticate using her registered passkey.
If Alice uses her phone, a prompt appears: "Scan your fingerprint" or "Enter your PIN." If she uses a hardware key, she might be asked to touch it or enter its PIN.
Upon successful authentication, her device cryptographically signs the challenge. This signed response is sent back to your application, which then forwards it to Auth0. Auth0 verifies the signature using the public key associated with Alice’s passkey, and if valid, logs her in without ever needing her password.
The core problem passkeys solve is the inherent insecurity and user friction of passwords. Passwords are phishable, guessable, and often reused across multiple sites, making them a prime target for attackers. Passkeys, based on public-key cryptography and hardware-backed authenticators, eliminate these vulnerabilities. They are resistant to phishing because the private key never leaves the user’s device, and they are resistant to brute-force attacks due to the cryptographic nature of the authentication.
Internally, Auth0 manages passkey registration and authentication through its FIDO2/WebAuthn integration. When a user registers a passkey, Auth0 stores the corresponding public key (and other metadata like the credential ID) securely associated with their user profile. During login, Auth0 generates a challenge, sends it to the client, and then verifies the signed assertion provided by the client’s authenticator against the stored public key.
The levers you control in Auth0 for passkeys are primarily within the "Authentication" -> "Passwordless" section, specifically under the "WebAuthn" tab. Here, you can:
- Enable/Disable WebAuthn: This is the master switch.
- Choose Authenticator Attachment: You can restrict users to specific types of authenticators, such as
platform(e.g., Touch ID, Windows Hello) orcross-platform(e.g., hardware security keys), or allow both. - Set Timeout: Define how long the user has to complete the passkey authentication after the challenge is issued.
- Configure Relying Party (RP) ID: This is crucial for security. It’s the domain name that your passkey authenticator will trust. It must match your application’s domain, typically
your-app.auth0.comor a custom domain. - Set Origin: Similar to the RP ID, this specifies the allowed origins that can initiate WebAuthn ceremonies. It’s usually your application’s URL, like
https://your-app.com.
When setting up the Relying Party ID and Origin in Auth0, you need to be precise. The RP ID should be set to your Auth0 tenant’s domain or your custom domain (e.g., login.yourcompany.com). The Origin should be your application’s scheme and host (e.g., https://app.yourcompany.com). Mismatching these can lead to authentication failures, as the browser will reject the WebAuthn ceremony if the origin or RP ID doesn’t match what the authenticator expects. This prevents a malicious site from impersonating your legitimate site to steal credentials.
The most surprising mechanical detail is how credential IDs are handled. When a user registers a passkey, Auth0 doesn’t just store the public key; it also stores a unique credentialId generated by the authenticator. During login, the client sends this credentialId back to Auth0. Auth0 uses this ID to quickly look up the correct public key for verification, rather than iterating through all of a user’s registered public keys. This makes the verification process efficient, even for users with multiple passkeys registered across different devices.
The next hurdle you’ll encounter is managing passkey recovery for users who lose access to all their registered authenticators.