Pega una respuesta de registro o autenticación serializada para inspeccionar sus datos. La decodificación muestra los campos, pero no valida firmas, atestación ni el desafío del servidor.
Se ejecuta localmente en tu navegadorEl servidor debe verificar desafío, origen, hash RP ID, presencia o verificación, firma, algoritmos, attestation y contador.
Esta página lee una PublicKeyCredential serializada — el JSON que la parte usuaria recibe de navigator.credentials.create() o navigator.credentials.get() — y convierte sus dos mitades en campos legibles: normalmente la vía más rápida para ver qué contenía realmente un registro o una aserción que falla. clientDataJSON se decodifica desde Base64URL y se analiza, y los datos del autenticador se separan en el hash del RP ID, el byte de flags, el contador de firmas y, en un registro, el AAGUID, el ID de credencial y la clave pública COSE.
Todo se ejecuta en el navegador. La página no llama a navigator.credentials, no contacta con ninguna parte usuaria y no envía la credencial a ningún sitio. Decodificar no es verificar: la firma, la declaración de attestation y la comparación del desafío corresponden a tu servidor.
El byte de flags describe la ceremonia, no la credencial. UP indica que hubo un usuario presente; UV, que se verificó con PIN o biometría; BE, que la credencial puede copiarse a otro autenticador, y BS, que ahora mismo lo está: una passkey sincronizada activa ambos. AT marca los datos de credencial attestados (AAGUID, ID de credencial y clave pública) que solo existen en un registro, y ED marca datos de extensión.
El contador de firmas es un entero sin signo de 32 bits que el autenticador incrementa en cada aserción. Compararlo con el valor guardado para esa credencial es la comprobación clásica de clones, pero un contador que nunca avanza no demuestra nada por sí solo: muchos autenticadores de plataforma devuelven cero de forma permanente. El hash del RP ID es el SHA-256 del identificador de la parte usuaria para el que se creó la credencial; cotejarlo con el valor esperado es lo que evita que una credencial capturada en un sitio se reutilice en otro.
clientDataJSON es JSON codificado en Base64URL que el navegador compone con el desafío, el origen y el tipo de ceremonia (webauthn.create o webauthn.get). La página lo decodifica, lo analiza e indica crossOrigin cuando el navegador marcó el flujo como embebido en otra página. Los bytes que siguen son una estructura binaria compacta: 32 bytes de hash del RP ID, un byte de flags, cuatro bytes de contador y, solo si el flag AT está activo, los datos de credencial attestados.
Una respuesta de registro incluye un attestationObject, un mapa CBOR que guarda los mismos datos del autenticador bajo authData; la página recorre el mapa CBOR para llegar a ellos. El formato y la declaración de attestation que lo acompañan no se muestran ni se comprueban aquí. Los campos que el navegador añade alrededor de la respuesta, como transports y clientExtensionResults, tampoco forman parte del informe.
Una credencial decodificada es una evidencia, no una prueba. La parte usuaria debe comparar el desafío con el que emitió en esa sesión, comprobar que el origen es el suyo, cotejar el hash del RP ID con el RP ID esperado y verificar la firma sobre los datos del autenticador y el SHA-256 de clientDataJSON con la clave pública que guardó en el registro.
También debe aplicar su propia política de verificación de usuario y de attestation, limitar los algoritmos que acepta y decidir qué significan el contador de firmas y los flags de copia para su modelo de amenaza. Esta página nombra los valores COSE que reconoce —ES256, EdDSA, ES384, ES512, PS256, PS384, PS512, RS256, RS384, RS512, con las curvas P-256, P-384, P-521, Ed25519 y Ed448— y muestra cualquier otro como su número sin procesar, que es una etiqueta y no una decisión de política.