Cole uma resposta serializada de registro ou autenticação para examinar os dados do cliente e do autenticador. A decodificação não verifica assinaturas, atestação nem o desafio do servidor.
Funciona localmente no seu navegadorO servidor deve verificar desafio, origem, hash do RP ID, presença ou verificação, assinatura, algoritmos, attestation e contador.
Esta página lê uma PublicKeyCredential serializada — o JSON que a parte confiante recebe de navigator.credentials.create() ou navigator.credentials.get() — e transforma as duas metades em campos legíveis — normalmente o caminho mais rápido para ver o que um registro ou uma asserção que falha realmente continha. O clientDataJSON é decodificado de Base64URL e analisado, e os dados do autenticador são separados no hash do RP ID, no byte de flags, no contador de assinaturas e, em um registro, no AAGUID, no ID da credencial e na chave pública COSE.
Tudo roda no navegador. A página não chama navigator.credentials, não contata nenhuma parte confiante e não envia a credencial para lugar nenhum. Decodificar não é verificar: a assinatura, a declaração de attestation e a comparação do desafio ficam no seu servidor.
O byte de flags descreve a cerimônia, não a credencial. UP indica que havia um usuário presente; UV, que ele foi verificado com PIN ou biometria; BE, que a credencial pode ser copiada para outro autenticador, e BS, que ela está copiada agora — uma passkey sincronizada liga os dois. AT marca os dados de credencial atestados (AAGUID, ID da credencial e chave pública) que só existem em um registro, e ED marca dados de extensão.
O contador de assinaturas é um inteiro sem sinal de 32 bits que o autenticador incrementa a cada asserção. Compará-lo com o valor guardado para aquela credencial é a checagem clássica de clones, mas um contador que nunca se move não prova nada sozinho: muitos autenticadores de plataforma devolvem zero para sempre. O hash do RP ID é o SHA-256 do identificador da parte confiante para o qual a credencial foi criada; compará-lo com o valor esperado é o que mostra que uma credencial capturada em um site não está sendo repetida em outro.
O clientDataJSON é um JSON em Base64URL que o navegador monta com o desafio, a origem e o tipo de cerimônia (webauthn.create ou webauthn.get). A página o decodifica, o interpreta e informa crossOrigin quando o navegador marcou o fluxo como embutido em outra página. Os bytes seguintes são uma estrutura binária compacta: 32 bytes de hash do RP ID, um byte de flags, quatro bytes de contador e, só se o flag AT estiver ligado, os dados de credencial atestados.
Uma resposta de registro carrega um attestationObject, um mapa CBOR que guarda os mesmos dados do autenticador em authData; a página percorre o mapa CBOR para chegar até eles. O formato e a declaração de attestation ao lado dele não são exibidos nem conferidos aqui. Campos que o navegador acrescenta em volta da resposta, como transports e clientExtensionResults, também não fazem parte do relatório.
Uma credencial decodificada é evidência, não prova. A parte confiante ainda precisa comparar o desafio com o que emitiu para aquela sessão, conferir se a origem é a sua, comparar o hash do RP ID com o RP ID esperado e verificar a assinatura sobre os dados do autenticador e o SHA-256 do clientDataJSON com a chave pública guardada no registro.
Também precisa aplicar a própria política de verificação de usuário e de attestation, restringir os algoritmos que aceita e decidir o que o contador de assinaturas e os flags de backup significam para o seu modelo de ameaça. Esta página nomeia os valores COSE que reconhece — ES256, EdDSA, ES384, ES512, PS256, PS384, PS512, RS256, RS384, RS512, com as curvas P-256, P-384, P-521, Ed25519 e Ed448 — e mostra qualquer outro valor como o número bruto, que é um rótulo e não uma decisão de política.