Ferramentas de desenvolvedor · Decodificador JWT
Anatomia de um JWT: Divisão em pontos e decodificação Base64url
· Como funciona
jwt codificação segurança
Um JWT são três segmentos base64url separados por pontos. Esta postagem decodifica cada parte manualmente, explica por que o segmento de assinatura não é texto e mostra o que um decodificador pode ou não dizer.
A longa string no cabeçalho Authorization — o que você está vendo e por que tem exatamente dois pontos
Um token de portador geralmente chega em um cabeçalho de autorização como uma sequência compacta e separada por pontos. Um JWT típico assinado no formato JWS compacto possui três segmentos e, portanto, dois pontos de separação. Um token ativo é uma credencial: não cole tokens de produção em uma demonstração.
Serialização compacta — cabeçalho, carga útil e assinatura como três segmentos base64url
Na serialização compacta JWS, o primeiro segmento é o cabeçalho protegido, o segundo é a carga útil e o terceiro é uma assinatura ou MAC. A assinatura cobre os dois primeiros segmentos codificados, unidos por um ponto. A divisão da string localiza os segmentos; não pode estabelecer confiança.
Base64url sem preenchimento — o alfabeto JWS usa e por que os segmentos não têm sinais de igual à direita
Base64url usa - e _ no lugar de + e / no Base64 comum. Compacto JWS omite o final = preenchimento; um decodificador pode restaurar o preenchimento antes da decodificação. A decodificação produz bytes. Para cabeçalho e declarações JSON, decodifique os bytes como UTF-8 antes de analisar o texto.
O cabeçalho — um pequeno objeto JSON que nomeia o algoritmo e, muitas vezes, a chave
O cabeçalho geralmente é JSON contendo alg e às vezes um identificador de chave, garoto. Estas são afirmações feitas pelo próprio token. Um verificador deve impor sua própria política de algoritmo permitido e obter com segurança a chave apropriada; ler alg sozinho não é autorização.
A carga útil — um objeto JSON de reivindicações, legível por qualquer pessoa que possua o token
A carga útil contém declarações como sub, exp e aud. Qualquer pessoa que possua o token pode lê-los; codificação não é criptografia. Um exp NumericDate conta os segundos desde a época Unix, mas uma declaração não verificada não tem autoridade. Não armazene segredos em uma carga legível.
A assinatura — bytes brutos nos dois primeiros segmentos, sem sentido como texto e inúteis sem uma chave
O último segmento são bytes de assinatura codificados em base64url, não um terceiro objeto JSON. Validá-lo requer um algoritmo criptográfico, uma chave e uma política de aplicação. ToolAcre deliberadamente não realiza verificação: ele relata a presença de assinatura e sempre marca subscriptionVerified como falso.
Exemplo resolvido - decodificando um token de amostra segmento por segmento, incluindo o JSON que aparece
Pegue o cabeçalho de demonstração não confidencial {"alg":"HS256","typ":"JWT"} e a carga útil {"sub":"demo"}. Suas codificações base64url são eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 e eyJzdWIiOiJkZW1vIn0. A decodificação recupera o JSON. Acrescentar um terceiro segmento arbitrário não torna o token autêntico.
Conclusão: decodificação é leitura, não confiança - o decodificador ToolAcre JWT mostra o cabeçalho e a carga útil e nunca verifica a assinatura, então nada que ele mostra prova que o token é genuíno
Decodificar é ler, não confiar. Use o decodificador ToolAcre JWT para cabeçalho, reivindicações e avisos de um token descartável; use o verificador confiável do seu aplicativo para decidir se um token assinado é válido. As declarações exibidas por si só nunca devem conceder acesso.