Português (Brasil)

Ferramentas de desenvolvedor · Decodificador JWT

O cabeçalho JWT explicado: alg, typ, kid e os campos para desconfiar

· Como funciona

jwt segurança autenticação

Um cabeçalho JWT decodificado parado em um limite de confiança do verificador
Ilustração vetorial original ToolAcre

O cabeçalho informa ao verificador como o token foi assinado e qual chave usar. Esta postagem explica cada campo de cabeçalho comum, em que um verificador pode confiar e quais campos nunca devem ser confiáveis ​​no próprio token.

O pequeno objeto JSON que ninguém lê — e as decisões de verificação que ele influencia

O cabeçalho é pequeno o suficiente para ser ignorado, mas seus campos frequentemente participam do roteamento de verificação. Isso torna perigoso confundir visibilidade com autoridade. ToolAcre decodifica o cabeçalho como um objeto JSON e mostra suas propriedades, mas cada byte veio do detentor do token e permanece como entrada não confiável.

Um verificador pode usar um valor de cabeçalho apenas dentro das restrições estabelecidas a partir de uma configuração confiável. Não deve permitir que o token invente um algoritmo aceito, emissor ou fonte de chave remota. O trabalho do decodificador termina em JSON legível mais avisos; ele nunca escolhe uma chave ou produz uma decisão de permissão ou negação.

exibição alg: o decodificador explica apenas os algoritmos nomeados em sua implementação

`alg` declara o algoritmo que o token afirma ter sido usado. ToolAcre possui notas explicativas para HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 e PS512, além de um aviso para `none`. Qualquer outra string é exibida como não reconhecida em vez de ser tratada como suportada.

Esta lista é um recurso de exibição, não um catálogo de algoritmos que ToolAcre pode verificar: ela não verifica nenhum deles. Um back-end deve fixar suas escolhas permitidas de forma independente e rejeitar uma incompatibilidade. A leitura de `alg: RS256` não pode provar que RSA foi usado, assim como a leitura de `alg: none` não pode autorizar com segurança um token não assinado.

typ e cty — declarando o tipo de token, o perfil at+jwt para tokens de acesso e JWTs aninhados

`typ` descreve o tipo de mídia ou perfil que o produtor pretende. ToolAcre avisa quando um valor de string difere de `JWT`; ele não impõe a semântica do perfil. Um campo `cty` pode descrever conteúdo aninhado, mas o decodificador atual não possui caminho de processamento de token aninhado e não interpreta esse campo.

A digitação explícita pode ajudar um verificador a manter diferentes classes de tokens separadas quando sua política define valores esperados. O cheque ainda pertence a esse verificador. Um token não pode se tornar um token de acesso simplesmente anunciando um rótulo preferido, e um painel de decodificação não pode determinar qual endpoint do aplicativo deve consumi-lo.

kid — o identificador de chave que permite aos verificadores girar as chaves sem tempo de inatividade

`kid` é um identificador de chave, não um material de chave e não uma prova de propriedade. Um serviço que alterna várias chaves confiáveis ​​pode usar um contexto de emissor autenticado e um identificador restrito para localizar um candidato. O identificador deve permanecer como entrada para uma pesquisa controlada em vez de um caminho de arquivo, fragmento de consulta ou URL arbitrário.

ToolAcre deixa `kid` visível no cabeçalho JSON mas não resolve. Essa restrição é importante: nenhum armazenamento de chaves confiável está disponível para uma página de decodificação pública. Se um 401 seguir a rotação, compare o identificador exibido com o inventário de chaves e registros do lado do servidor sem presumir que a chave sugerida do token é legítima.

jku, x5u, jwk e x5c — campos de cabeçalho que apontam para chaves e por que um verificador nunca deve buscá-los ou confiar cegamente neles

Campos como `jku` e `x5u` podem nomear locais, enquanto `jwk` e `x5c` podem conter dados relacionados a chaves. A presença deles não torna esses locais ou valores confiáveis. Buscar um URL ou aceitar material incorporado apenas porque um cabeçalho não verificado forneceu uma decisão de segurança ao solicitante.

Um verificador seguro obtém chaves por meio de um relacionamento de emissor e de uma política de rede estabelecida fora do token. ToolAcre não busca URLs de cabeçalho nem cria confiança a partir de chaves incorporadas. Durante a revisão, ver um desses campos é um aviso para inspecionar a configuração do verificador, não uma instrução para seguir o cabeçalho.

crit — extensões que um verificador deve compreender ou rejeitar

`crit` sinaliza que extensões específicas requerem compreensão por parte do destinatário. Um verificador que suporte tal extensão precisa de um caminho explícito de implementação e rejeição para nomes críticos desconhecidos. Ignorar um marcador crítico desconhecido pode fazer com que o produtor e o consumidor interpretem o conteúdo protegido de forma diferente.

A implementação somente decodificação não processa `crit`, portanto pode mostrar a matriz bruta sem reivindicar compatibilidade. Este é outro limite entre inspeção e validação. Se um token de produção depender de extensões críticas, verifique o comportamento na biblioteca e configuração reais, em vez de inferir o suporte de JSON legível.

Exemplo resolvido – lendo um cabeçalho realista e decidindo quais campos informam a verificação e quais são meramente informativos

Considere `{"alg":"RS256","typ":"JWT","kid":"rotate-7"}`. ToolAcre imprime todos os três campos e explica que a verificação RS256 precisa de uma chave pública do emissor. Um revisor pode anotar o algoritmo declarado e o identificador de chave e, em seguida, compará-los com a política fixada do servidor e o conjunto de chaves confiáveis.

Os campos informam a investigação, mas não decidem nada de forma independente. Se o servidor permitir apenas outro algoritmo, não conseguir encontrar `rotate-7` no conjunto de emissores correto ou rejeitar a assinatura, o cabeçalho legível não substituirá esse resultado. Da mesma forma, a alteração do texto do cabeçalho sem recalcular uma assinatura válida não deve ser aceita.

Conclusão: o cabeçalho é uma entrada, não uma autoridade — o decodificador ToolAcre JWT mostra o cabeçalho para que você possa lê-lo; o verificador deve decidir independentemente em que confiar

Trate o cabeçalho JWT como entrada, não como autoridade. Seus valores podem ajudar a selecionar entre opções já autorizadas pela configuração, identificar um provável problema de rotação ou explicar uma incompatibilidade de perfil. Eles não podem estabelecer confiança em seu próprio algoritmo, chave, URL ou tipo de token.

Use ToolAcre para ler um cabeçalho de teste e revelar valores suspeitos, como `alg` ausente, `none` ou um `typ` inesperado. Em seguida, vá para o verificador configurado para cada decisão consequente. A decodificação não prova autenticidade, integridade, autorização ou identidade do emissor, independentemente da aparência plausível do cabeçalho.