Ferramentas de desenvolvedor · Decodificador JWT
Token de ID versus token de acesso: por que um OpenID Connect JWT não é uma chave API
· Fundo
jwt oauth autenticação
Ambos podem ser JWTs do mesmo provedor, mas respondem a perguntas diferentes. Esta postagem explica o que um token de ID e um token de acesso contêm, quem deve consumi-los e como diferenciá-los por decodificação.
O API rejeita um token que parece perfeitamente válido — porque nunca foi concebido para o API
Um API pode rejeitar um token bem formado e assinado corretamente porque essa credencial foi emitida para outro consumidor e finalidade. “É um JWT” descreve um formato possível, não uma permissão para enviá-lo para qualquer lugar. Os tokens de ID e os tokens de acesso respondem a diferentes perguntas em um fluxo de identidade.
ToolAcre pode expor padrões de cabeçalho e carga útil que suportam depuração, mas não pode autenticar o token ou validar um perfil do OpenID Connect. A classificação final deve vir do contrato do fornecedor, do fluxo de emissão e do resultado da verificação confiável, e não da inspeção visual.
As reivindicações de token de identificação podem sugerir uso de identidade; este decodificador genérico não valida um perfil OpenID Connect
Um token de ID comunica informações de autenticação ao cliente que solicitou a entrada. Dependendo do perfil, as declarações visíveis podem incluir um nonce, tempo de autenticação, métodos de autenticação ou um hash relacionado a outro token. Esses campos não são concessões de autorização API genéricas.
O decodificador trata `auth_time` como um campo em formato de tempo e exibe outros nomes como específicos do aplicativo, a menos que estejam entre os sete principais. Ele não valida nonce, `at_hash`, `amr` ou semântica do público do cliente. Uma carga útil de identidade legível permanece não confiável até que o cliente a valide corretamente.
Os tokens de acesso podem ser JWTs ou opacos; apenas JWTs de três partes cabem neste decodificador
Um token de acesso autoriza chamadas para um servidor de recursos sob um sistema de autorização. Pode ser um JWT ou uma string opaca. Somente a forma assinada de três partes se ajusta à rota de ToolAcre; um token opaco não possui estrutura geral do lado do cliente para decodificar e não deve ser forçado por meio desta ferramenta.
Um token de acesso JWT pode transportar informações de público e escopo, mas esses valores precisam de verificação autenticada e política de recursos. O painel do navegador não implementa um servidor de recursos e não pode dizer se um escopo permite uma operação específica.
Tokens de atualização — geralmente opacos, nunca destinados a serem decodificados e nunca enviados para um API
Um token de atualização oferece suporte à obtenção de credenciais de acesso de substituição de acordo com as regras do provedor. Geralmente é opaco e não se destina a APIs de recursos. É também uma credencial de alto valor, portanto colá-la em um decodificador cria riscos sem um benefício de diagnóstico confiável.
Não infira que todo valor em forma de token deve ser decodificado. Use ferramentas do provedor e logs controlados para falhas de atualização. O aviso explícito de ToolAcre contra tokens de produção se aplica com força especial aqui, e seu analisador de três segmentos não oferece operação de atualização.
Os públicos são diferentes — o ID do cliente em um token de ID versus o recurso em um token de acesso
O público é uma pista forte porque o consumidor pretendido é diferente. Um token de ID geralmente tem como alvo o cliente, enquanto um token de acesso tem como alvo um recurso. Os identificadores e representações exatos dependem do provedor e do perfil, portanto, este artigo não inventa um padrão de string universal.
Um cabeçalho `typ` também pode fornecer um rótulo explícito, mas permanece como dados controlados por token até a verificação. ToolAcre avisa apenas quando uma string `typ` difere de `JWT`; ele não reconhece todos os rótulos de perfil nem os transforma em uma decisão de autorização.
Exemplo resolvido: compare campos visíveis sem tratá-los como prova do tipo de token
Decodifique dois exemplos sintéticos: um que carrega declarações de autenticação orientadas ao cliente e outro que carrega um público e escopo de recursos. Registre as diferenças em `aud`, `typ` e nomes de carga útil. O exercício ensina o que perguntar ao emissor, e não como provar a identidade de qualquer um dos exemplos.
Um token fabricado pode copiar os mesmos rótulos e um token real pode usar convenções específicas do provedor. Confirme o tipo da resposta e documentação da emissão e, em seguida, valide-o com o consumidor pretendido. A saída do decodificador é a evidência de apoio, nunca a autoridade decisória.
O que isso não cobre: os fluxos OAuth que emitem esses tokens, que são um tópico separado
Esta comparação não explica o código de autorização, o dispositivo ou outros fluxos que emitem tokens. Também não cobre etapas de validação específicas do provedor, introspecção opaca de token de acesso ou rotação de atualização. Esses assuntos dependem do ecossistema e da implantação selecionados.
Mantenha a questão de depuração imediata restrita: qual credencial o cliente recebeu, quem é o consumidor pretendido e qual componente confiável a valida? Responder a essas três perguntas evita que uma forma JWT genérica apague funções de protocolo.
Conclusão: observe aud e digite antes de enviar - o decodificador ToolAcre JWT permite verificar que tipo de token você está segurando
Observe o público e digite antes de enviar um token, mas não confie em nenhum dos campos até que a verificação seja bem-sucedida. Um token de ID pertence ao seu limite de validação do cliente; um token de acesso pertence ao seu servidor de recursos. Um token de atualização pertence ao processo de atualização do provedor, não a API.
ToolAcre ajuda a ler exemplos seguros de três partes e não pretende classificá-los ou validá-los. Use-o para detectar erros prováveis e deixe que o fluxo documentado e o verificador configurado de forma independente estabeleçam o verdadeiro propósito da credencial.