Ferramentas de desenvolvedor · Decodificador JWT
As sete reivindicações JWT registradas: iss, sub, aud, exp, nbf, iat e jti
· Fundo
jwt formatos de dados autenticação
RFC 7519 reserva sete nomes de declarações com significados e tipos definidos. Esta postagem explica cada um deles, os tipos StringOrURI e NumericDate por trás deles e como coexistem declarações registradas, públicas e privadas.
Quais nomes de declarações devo usar? - a questão do design que o registro responde
A escolha de nomes de declarações é, em parte, uma decisão de interoperabilidade. A reutilização de um nome registrado dá aos leitores e bibliotecas um significado estabelecido, enquanto nomes específicos de aplicativos exigem documentação local. ToolAcre reconhece sete nomes principais em sua tabela de descrição e deixa outras declarações visíveis sem atribuir semântica.
Um nome familiar não é automaticamente confiável. O decodificador lê qualquer objeto que o token contenha e nunca verifica sua assinatura. O vocabulário registrado ajuda os humanos a classificar os dados; somente um verificador confiável pode estabelecer que um emissor forneceu o valor protegido.
iss e sub são exibidos como strings; esta implementação não impõe a sintaxe StringOrURI
`iss` identifica quem o token afirma ter emitido e `sub` identifica de quem ou do que se trata. ToolAcre descreve ambos e exibe seus valores, mas sua implementação não valida uma gramática StringOrURI nem compara qualquer campo com a configuração do serviço.
Um verificador deve vincular o emissor esperado ao material chave confiável e interpretar o assunto no namespace desse emissor. Copiar uma string de emissor conhecida em uma carga fabricada faz com que o decodificador pareça convincente sem estabelecer a origem. Utilize estes campos somente após verificação criptográfica.
aud — os destinatários pretendidos, como uma string ou array
`aud` descreve os destinatários pretendidos e pode ser representado como um valor ou uma lista de acordo com as regras de token aplicáveis. A tabela de declarações genéricas de ToolAcre preserva matrizes como texto JSON, mas não decide se o serviço atual aparece neles.
O público é contextual. O mesmo token autenticado pode ser apropriado para um API e errado para outro. Um servidor de recursos precisa de um identificador esperado em uma configuração confiável e deve rejeitar uma incompatibilidade em vez de deixar o token definir onde deve ser aceito.
exp, nbf e iat — as três declarações NumericDate que vinculam um token no tempo
`exp`, `nbf` e `iat` são declarações NumericDate. ToolAcre trata números finitos como segundos desde a época, multiplica por 1,000 para exibição de data e rótulos de expiração ou não antes em relação ao relógio do navegador. Ele não define margem de manobra nem impõe aceitação do servidor.
Uma expiração marca um limite final reivindicado, e não uma prova de que o token já foi válido. Not-before marca um limite de início reivindicado e emitido em registra um tempo de criação reivindicado. Cada um pode ser forjado em uma carga útil, portanto a aritmética do tempo deve seguir a verificação da assinatura em um fluxo confiável.
jti — um identificador exclusivo para detecção de replay e listas de bloqueio
`jti` é um identificador de token. Os sistemas podem usar um identificador autenticado e gerado adequadamente para rastreamento de reprodução ou estado de revogação, mas a declaração por si só não fornece nenhuma das propriedades. ToolAcre descreve-o como um ID de token para detecção de repetição e exibe seu valor exato.
Exclusividade, armazenamento e comportamento de pesquisa pertencem à arquitetura do emissor e do verificador. Um decodificador não pode determinar se outro token reutilizou o identificador ou se uma lista de bloqueios o contém. Trate-o como um valor de correlação candidato até que o sistema confiável circundante forneça evidências.
Descrições registradas e reivindicações específicas do aplicativo na exibição ToolAcre
A implementação distingue nomes registrados apenas por meio de texto explicativo. Cada propriedade de carga útil ainda é retornada por `listClaims`; nomes desconhecidos recebem uma descrição nula e a UI os rotula como específicos do aplicativo. Ele não consulta um registro público nem evita colisões de nomes privados.
Esse limite evita reivindicar mais do que a fonte prova. As equipes devem documentar suas reivindicações privadas e escolher nomes resistentes a colisões quando a interoperabilidade for importante. A ausência de uma descrição no decodificador significa “não nesta tabela local de sete nomes”, não “inválido” ou “seguro para ignorar”.
Exemplo resolvido - lendo uma carga realista e classificando cada reivindicação
Considere `{"iss":"https://issuer.example","sub":"user-7","aud":["orders"],"exp":1717246800,"nbf":1717243100,"iat":1717243200,"jti":"demo-9","tenant":"north"}`. ToolAcre descreve os sete campos registrados e rótulos `tenant` específicos do aplicativo durante a formatação dos três tempos numéricos.
Esta classificação ajuda a revisar o design da carga útil. Não autentica URL, assunto, público, datas, identificador ou locatário. Um token forjado pode reproduzir o objeto com exatidão. Insira apenas declarações verificadas na lógica de autorização e, em seguida, aplique os valores esperados do serviço de consumo.
Conclusão: use os nomes registrados quando eles couberem - o decodificador ToolAcre JWT mostra a carga útil para que você possa ver quais reivindicações um emissor real define
Use nomes registrados quando seus significados definidos se adequarem, porque um vocabulário reconhecível reduz traduções desnecessárias. Mantenha os campos privados documentados e mínimos. Não sobrecarregue `sub`, `aud` ou uma declaração de tempo com um significado local diferente apenas porque o código downstream já analisa essa chave.
ToolAcre pode mostrar quais nomes um token seguro carrega e como suas declarações numéricas são renderizadas. Não pode certificar nenhum valor. O resultado útil da decodificação é um inventário para revisão; o resultado útil da verificação e da política é uma decisão, e estes permanecem separados.