WebAuthn / 通行密钥查看器
粘贴 navigator.credentials.create() 或 .get() 返回的内容——完整的 JSON 或单个 base64url 字段均可。每个部分都会被解码并加以解释:clientDataJSON、逐位解析的认证器数据标志、AAGUID、凭证 ID、COSE 公钥以及证明声明。对于登录,ECDSA P-256 签名会直接在此页面中验证。
100% 本地运行——所有操作都在你的浏览器中完成,不会向任何服务器发送数据
navigator.credentials.create() 返回的响应——新建的通行密钥。
解码结果
尚未粘贴任何内容
所有内容都在本地解码在浏览器控制台中执行一次注册或登录,然后复制结果。在 Chrome 和 Safari 中,credential.toJSON() 返回的正是此输入框所需的 JSON;较旧的代码路径则需要使用 credential.response 中的 base64url 值。也可以点击加载示例,查看签名能够验证通过的真实通行密钥响应。
How it works
A passkey is an ECDSA key pair — almost always on the P-256 curve — created by your phone, laptop or security key. The private half never leaves that device. Registration hands your server the public half; every later login is a signature made with the private half over data your server chose. There is no shared secret to steal, and the browser refuses to sign for a site the credential was not created on, which is what makes passkeys phishing-resistant.
The browser returns two or three base64url blobs. clientDataJSON is plain JSON describing what the browser saw: the ceremony type, your challenge, and the real origin. authenticatorData is a packed binary record: 32 bytes of SHA-256(RP ID), one flags byte, a 4-byte counter, and — during registration — the AAGUID, the credential ID and the new public key as a CBOR-encoded COSE_Key. During registration that record is wrapped in an attestationObject, a CBOR map that adds the authenticator's optional statement about its own make and model.
Verifying a login is one line of maths: verify(signature, SHA-256(authenticatorData ‖ SHA-256(clientDataJSON)), publicKey). Note what is not in there — the challenge and the origin are only covered because they sit inside clientDataJSON, so a valid signature is necessary but never sufficient: your server still has to read those fields and compare them with what it expects. WebAuthn signatures are ASN.1 DER, not the raw r‖s format JWTs use, which is a common source of "valid signature that will not verify".
The same page checks the attestation statement of a registration in every format the WebAuthn registry defines — packed, tpm, android-key, android-safetynet, fido-u2f, apple, none and compound — and assertion signatures with every COSE algorithm a credential may carry: ES256, ES384, ES512, EdDSA, RS256, PS256 and their relatives. A valid attestation proves that whoever holds the attestation key signed this registration; whether that key belongs to hardware you trust is a separate decision, made by chaining its certificates to a root you accept — normally one the FIDO Metadata Service publishes, which the AAGUID Lookup reads for you.
This page does all of it in your browser: the CBOR decoder and the WebAuthn parsers are written from scratch, ECDSA and EdDSA signatures are checked with the audited @noble/curves library, and RSA signatures with a few dozen lines of RFC 8017 arithmetic. Nothing you paste is uploaded, logged or stored — which matters, because a real response identifies a real credential of a real user.