Skip to content
Start with Identity
Join free
Free tool · WebAuthn / FIDO2 · passkeys

WebAuthn Passkey Tester

Create a test passkey on this device or a security key, sign in with it, and see exactly what the authenticator returned: the flags, AAGUID, sign count, transports, algorithm and attachment, with what each one means for a relying party. Protocol background: WebAuthn and FIDO2 explained.

Checking browser support...

Relying party ID: . Registered this session: 0. Public keys are held in page memory only and vanish on reload.

How it works and what to check

Registration calls navigator.credentials.create() with a random challenge, a random user ID and this site's hostname as the relying party ID. The authenticator returns an attestationObject (CBOR) and clientDataJSON. The page decodes the CBOR, splits the authenticator data into its fields (a 32-byte SHA-256 hash of the RP ID, one flags byte, a 4-byte counter, then the AAGUID, credential ID and COSE public key), and keeps the public key in memory. Sign-in calls navigator.credentials.get(), and the page verifies the assertion signature over the authenticator data plus the SHA-256 of clientDataJSON with WebCrypto (ES256, RS256 and Ed25519 where the browser supports it), the same check a real server performs.

What a relying party should check

  • Challenge, type and origin in clientDataJSON must match what the server issued and its own origin. This is what makes passkeys phishing-resistant: a look-alike domain produces a different origin and RP ID hash.
  • rpIdHash must be the SHA-256 of your RP ID.
  • UP must be set. UV must be set if you treat the passkey as multi-factor on its own; set userVerification to required when it matters, and check the flag on the server rather than trusting the request option.
  • BE and BS tell you whether a credential is synced. Policies that need device-bound keys (some workforce and regulated cases) can reject BE=1 at registration.
  • Sign count should increase on authenticators that use it. A value of 0 every time means no counter, which is normal for synced passkeys.
  • AAGUID and attestation identify the authenticator model. Trusting them requires validating the attestation statement against the FIDO Metadata Service; this tool shows the values but does not perform that validation.
  • Transports and attachment (internal, hybrid, usb, nfc, ble; platform or cross-platform) help you label credentials for users and pick sensible allowCredentials hints.

Try different settings

Set residentKey to required to create a discoverable passkey, then use "any discoverable passkey" to sign in without a username. Set attachment to cross-platform to use a security key or a phone over hybrid transport, and compare the BE flag and AAGUID with a platform passkey. For implementation, follow the add passkeys with WebAuthn recipe.

Related

Frequently asked questions

What do the UP, UV, BE and BS flags mean in WebAuthn?
They are bits in the authenticator data. UP (user present) means someone touched or approved the prompt. UV (user verified) means the authenticator checked a PIN or biometric. BE (backup eligible) means the credential can be synced or backed up, which marks a synced passkey. BS (backup state) means it is currently backed up. BE is fixed when the credential is created; BS can change.
What is an AAGUID?
The Authenticator Attestation GUID is a 16-byte identifier for the authenticator model, included in the attested credential data at registration. Relying parties use it to show which password manager or security key holds a passkey, or to restrict models. It can be all zeros when attestation is not requested.
Why is the passkey signature counter always 0?
The WebAuthn spec allows authenticators that do not implement a counter to always return 0, and synced passkeys generally do. A relying party should only treat a counter that fails to increase as a possible clone when the counter was non-zero before.
Does this WebAuthn tester send anything to a server?
No. The relying party is simulated inside this page: challenges are generated with crypto.getRandomValues, the responses are parsed in your browser, and the assertion signature is verified with WebCrypto. No request is sent to our server and nothing is stored there. The passkey itself is saved on your authenticator, so delete it afterwards in your password manager or security key settings.
Is the passkey created here usable anywhere else?
No. A passkey is bound to the relying party ID, which here is this site's domain, and this site has no account system that accepts it. It is a throwaway test credential.