Ferramentas de desenvolvedor · Decodificador JWT
Verificações de público e emissor: impedindo que um JWT seja reproduzido em outro lugar
· Por que é importante
jwt autenticação segurança
Um token emitido para um serviço pode ser apresentado a outro que compartilhe o mesmo emissor. Esta postagem explica como as verificações aud e iss impedem isso e como ler ambas as declarações em um token.
O serviço B aceita um token destinado ao serviço A – a reprodução entre serviços que uma assinatura válida não impede
Uma assinatura pode ser válida para um token emitido para um serviço diferente. Se várias APIs confiarem na mesma plataforma de identidade, mas ignorarem o contexto do destinatário, uma credencial destinada ao serviço A poderá ser reproduzida no serviço B. A integridade criptográfica por si só não responde quem deve consumi-la.
ToolAcre pode revelar `iss` e `aud` para que um desenvolvedor possa detectar uma incompatibilidade óbvia. Essas strings permanecem sem verificação até que a assinatura seja bem-sucedida, e a ferramenta do navegador nunca executa essa verificação. O servidor de recursos real deve impor tanto o seu relacionamento com o emissor quanto o público-alvo.
iss — vinculando um token ao emissor em que seu serviço confia e por que uma correspondência de string não é suficiente sem vinculação de chave
`iss` identifica a entidade para a qual as reivindicações de carga emitiram o token. Um verificador precisa de um emissor exato esperado em sua própria configuração e deve vincular essa identidade ao relacionamento correto de descoberta de chave. A comparação de texto sem a ligação criptográfica deixa espaço para um invasor copiar a string esperada.
O decodificador descreve `iss` como “quem criou o token”, mas esse é o significado registrado, não uma descoberta sobre um valor colado. O texto legível do emissor é uma evidência útil para a configuração de depuração. Ele não pode selecionar uma fonte de chave arbitrária ou autenticar-se.
aud — uma string ou array nomeando os destinatários pretendidos e a regra que um verificador deve encontrar nele
`aud` nomeia os destinatários pretendidos e pode aparecer como uma string ou uma coleção. A política do servidor de recursos deve encontrar-se no valor autenticado usando as regras de comparação exatas exigidas pelo seu perfil. Não deve aceitar um token apenas porque algum outro serviço familiar está listado.
ToolAcre carrega arrays como texto JSON em sua tabela de declarações, preservando sua estrutura visível para inspeção. Ele não conhece o identificador do API atual e não pode decidir uma correspondência. Essa ausência deliberada impede que um decodificador genérico invente um contexto de autorização que não possui.
azp e escopo — as declarações OpenID Connect e OAuth que refinam quem pode usar o token e para quê
`azp` e `scope` podem adicionar contexto sobre uma parte autorizada e permissões solicitadas em perfis que as definem. Eles não substituem verificações de audiência, emissor ou assinatura. Um nome de escopo é uma afirmação e não uma concessão de permissão até que o servidor de recursos mapeie um valor autenticado para sua própria política.
O decodificador atual trata essas declarações como declarações específicas do aplicativo porque sua tabela de descrição registrada cobre sete nomes principais. Ele exibe seus valores, mas não fornece semântica OpenID Connect ou OAuth. Consulte o perfil aplicável e o contrato do fornecedor antes de utilizá-los em uma decisão.
O padrão de deputado confuso – como um token legítimo se torna um ataque quando o público não é verificado
Um deputado confuso usa autoridade legítima num contexto não intencional. Um token aceito pelo serviço errado pode desencadear exatamente esse padrão, mesmo quando ninguém falsificou a assinatura. As verificações de público limitam onde as declarações autenticadas podem ser aplicadas, enquanto as verificações do emissor limitam quais afirmações o serviço considera.
É por isso que um sinalizador geral de “assinatura válida” ainda seria insuficiente. A autorização depende do destinatário e da operação. ToolAcre evita totalmente essa ambigüidade ao não relatar nenhum resultado de verificação, deixando o serviço consumidor combinar criptografia com política contextual.
Exemplo resolvido - lendo iss e aud de dois tokens no decodificador ToolAcre JWT e decidindo qual serviço deve aceitar cada um
Crie dois tokens inofensivos cujas cargas decodificadas diferem apenas em `aud`: um nomeia `service-a`, o outro `service-b`; ambos reivindicam o mesmo emissor. ToolAcre torna a diferença visível. Um verificador do serviço A não deve aceitar apenas esta exibição e deve rejeitar o público autenticado do serviço B.
Em seguida, inverta o exercício com duas strings emissoras. O texto esperado por si só não é suficiente, a menos que a verificação utilize chaves confiáveis para aquele emissor. Esses exemplos separam a inspeção da aceitação e mostram por que copiar as declarações aparentemente corretas em um token fabricado não altera nenhuma política confiável.
O que isto não cobre – verificação de assinatura, que o decodificador nunca realiza; Os cheques aud e iss só importam após a assinatura ser válida
As verificações de público e emissor só são importantes depois que a verificação criptográfica estabelece que os bytes protegidos correspondem ao material de chave confiável. ToolAcre não realiza nenhuma dessas verificações. Os seus resultados não podem estabelecer que uma reivindicação sobreviveu intacta ou que um emitente conhecido foi a sua autoria.
Também não busca metadados, escolhe chaves ou compara destinatários configurados. Use testes e registros de back-end para provar a rejeição do emissor e do público errados. Uma correspondência visual em um decodificador é uma pista de depuração, nunca uma evidência de autorização suficiente.
Conclusão: verifique para quem é, não apenas quem o assinou - o decodificador ToolAcre JWT mostra as declarações aud e iss que você precisa comparar
Verifique para quem é o token, não apenas o nome que ele diz que o assinou. O fluxo robusto autentica bytes protegidos sob um relacionamento de emissor confiável independente e, em seguida, requer um público aceitável e aplica regras de autorização específicas do serviço.
Use ToolAcre para ler valores de teste seguros e formular a próxima verificação do lado do servidor. Não escolha chaves de verificação de cabeçalhos não confiáveis ou dados de declaração e não transforme `iss`, `aud`, `azp` ou `scope` exibidos em uma concessão sem o fluxo confiável completo.