Resumo

  • Em 24 de agosto de 2026, o IESG aprovou a revisão 10 de draft-ietf-oauth-rfc8725bis como Best Current Practice. No congelamento das evidências, o texto ainda era um Internet-Draft na fila do RFC Editor; quando publicado, tornará o RFC 8725 obsoleto e atualizará o RFC 7519.
  • A principal regra operacional é tornar mutuamente exclusivos os validadores de diferentes espécies de JWT. Uma assinatura correta não basta: tipo, emissor, público, claims, cabeçalhos protegidos, algoritmo, chave e contexto da aplicação ainda precisam coincidir.

O alerta que tentou pagar uma conta

Uma plataforma recebe Security Event Tokens para relatar mudanças de conta. A API financeira da mesma empresa aceita tokens de acesso. As duas aplicações confiam no mesmo emissor e consultam o mesmo conjunto de chaves. Um token de evento legítimo chega à API; a biblioteca JWT confirma a assinatura e devolve sucesso.

A criptografia funcionou. A autorização não.

O cenário é um teste ilustrativo, não um incidente atribuído. Ele mostra a confusão entre JWT: um objeto emitido para uma finalidade é inserido em um contexto que espera outra. Não é preciso falsificar a assinatura quando o receptor confunde “o emissor disse isto” com “o emissor autorizou esta ação aqui”.

A correção não consiste apenas em trocar o algoritmo. O receptor de eventos e a API precisam de conjuntos de aceitação que não se sobreponham, mesmo quando formato, emissor, chave e alguns claims são compartilhados.

A aprovação ainda percorre a cadeia editorial

O anúncio oficial registra que “JSON Web Token Best Current Practices”, revisão 10, foi aprovado em 24 de agosto às 18h02 UTC para publicação como BCP. O trabalho veio do grupo OAuth.

Em 28 de agosto, o Datatracker ainda o classificava como Internet-Draft ativo, datado de 21 de agosto, atualizado no dia 25 e com expiração em 22 de fevereiro de 2027. O estado no IESG era RFC Ed Queue. O RFC Editor aguardava uma referência ainda não recebida. A IANA não previa novas ações de registro, embora o processo constasse como em andamento.

A decisão do IESG é notícia normativa concreta, mas não equivale a um número RFC, a uma publicação concluída nem à implantação em validadores. Se publicado como indicado, o documento substituirá o RFC 8725 e modificará a especificação básica de JWT, o RFC 7519.

Há quatro perguntas dentro de “JWT válido”

JWT organiza claims; ele não define uma única proteção. Pode aparecer como JWS assinado, JWE cifrado, objeto aninhado ou, quando a aplicação permite de modo expresso, JWT sem proteção. A serialização compacta com base64url e pontos também não deve ser confundida com todas as serializações JSON de JOSE.

O receptor precisa responder em sequência:

  1. o objeto usa exatamente a serialização admitida neste endpoint;
  2. assinatura ou criptografia autenticada foi validada com algoritmo permitido e chave correta;
  3. o objeto pertence à espécie de token consumida pela aplicação;
  4. os claims autorizam esta operação agora, para este emissor, público e sujeito.

Decifrar um JWE não valida automaticamente a assinatura interna. Analisar um objeto compacto não cria confiança. Confirmar um JWS não torna seus claims válidos em todo serviço que compartilha a chave.

typ precisa excluir, não apenas descrever

A revisão recomenda tipagem explícita quando houver risco de confusão. O tipo de Security Event Token definido pelo RFC 8417 oferece um discriminador útil. O valor genérico JWT, porém, só informa a família do contêiner e não identifica o contrato da aplicação.

O tipo é uma barreira, não a barreira inteira. Validadores de espécies diferentes devem ser mutuamente exclusivos. A separação pode usar tipos distintos, claims ou valores obrigatórios, cabeçalhos protegidos, chaves, públicos ou emissores diferentes.

O RFC 9068 cria um perfil JWT para tokens de acesso OAuth; o RFC 8417 faz isso para eventos de segurança. Ambos podem ser autênticos e, ainda assim, não podem substituir um ao outro. O consumidor escolhe o perfil antes de dar sentido autorizativo aos campos.

A migração deve reconhecer os tokens antigos sem typ. Exigi-lo de uma vez pode interromper clientes. Um começo compatível rejeita qualquer valor presente que seja diferente do esperado, mede ausências e coordena a obrigatoriedade futura com emissores e consumidores.

Público e emissor limitam o mandato

O emissor identifica quem fez a declaração; o público identifica para quem ela foi feita. Os dois precisam ser validados pelo perfil antes de qualquer claim alterar permissões, rotas ou dados.

Serviços A e B não formam automaticamente o mesmo público por pertencerem à mesma organização ou usarem o mesmo provedor de identidade. Administração comum não transforma um token destinado a A em credencial de B.

Nem sub tem significado universal. Pode representar uma pessoa, um cliente ou o objeto de um evento de segurança. A espécie de token fornece a semântica que o nome do campo, sozinho, não contém.

O token não escolhe a política criptográfica

A lista de algoritmos permitidos pertence ao receptor. alg é uma entrada a conferir, não uma ordem para escolher o método de validação. A revisão também associa cada chave a exatamente um algoritmo, evitando interpretações incompatíveis do mesmo material.

Cabeçalhos de seleção como kid, jku e x5u podem orientar consultas ou buscas remotas. Sem restrição, tornam-se caminhos de injeção ou de requisições do servidor a destinos arbitrários. Antes da validação são dados hostis; depois dela, ainda não autorizam acesso irrestrito à rede.

O texto reúne ainda limites de iteração para criptografia baseada em senha, limites de descompressão em JWE e identificadores de algoritmo totalmente especificados, como os do RFC 9864. São controles contra exaustão de recursos e ambiguidade, não apenas contra falsificação.

A trilha de uma decisão precisa sobreviver

O registro mínimo une bytes recebidos, serialização, endpoint, perfil esperado, cabeçalhos protegidos, lista de algoritmos, chave resolvida e seu único algoritmo, resultado criptográfico, tipo, emissor, público, claims e janela de tempo, estado de repetição ou revogação quando necessário, decisão, ação solicitada e efeito final.

Um log “JWT valid” apaga a distinção que a investigação procurará. Ele não diz qual perfil foi escolhido, qual público foi comparado nem se a validação produziu uma ação autorizada.

A disciplina do código em operação exige observar o consumidor real. O padrão define o mínimo; o teste de substituição, a rejeição e a ausência de efeito provam que a fronteira funciona.

Fontes