APRENDER. PRATICAR. EVOLUIR.Começar pelo contrato do recurso
Uma API fictícia de relatórios de fundos recebe um JWT assinado. A equipa confirma a assinatura e considera o pedido autorizado. Falta verificar para que recurso o token foi emitido, por quem, para que finalidade e durante que intervalo. O servidor de recursos precisa de uma política explícita, acordada com o emissor: algoritmos aceites, chaves associadas ao emissor, audience, tipo e claims exigidas. O formato genérico JWT não torna todas as claims obrigatórias. O perfil de access token do RFC 9068 exige mais informação, incluindo iss, exp, aud, sub, client_id, iat e jti. Documenta o perfil aplicado, sem assumir que qualquer sequência com três partes serve como credencial desta API.
Decodificar não autentica o conteúdo
O laboratório gera chaves RSA temporárias em memória e assina tokens sintéticos com RS256. Ler a parte de claims revela tenant e scope sem conhecer a chave privada: a codificação não oferece confidencialidade. Quando o exercício altera o tenant depois da assinatura, a verificação falha. Outra chave privada também não produz uma assinatura aceite pela chave pública fixada. Porém, um token corretamente assinado com audience diferente continua inadequado para o recurso. A verificação criptográfica e a validação de contexto respondem a perguntas distintas. Não coloques tokens reais em descodificadores públicos nem registes o bearer completo para facilitar diagnóstico; quem obtiver a credencial pode conseguir reutilizá-la enquanto os controlos a aceitarem.
Escolher confiança antes de ler indicações não fiáveis
O campo alg não deve permitir ao remetente escolher livremente a política criptográfica. O modelo aceita apenas RS256 e rejeita HS256 ou none, mesmo quando os restantes campos parecem corretos. Um kid identifica uma chave dentro do conjunto configurado; não cria confiança nessa chave. A fixture não segue URLs jku, não descarrega material remoto e rejeita extensões que não implementa. Em produção, a descoberta e atualização de chaves precisam de origens de confiança, limites e comportamento de falha definidos. Não uses um URL vindo do token como autorização para contactar qualquer destino. Para reduzir confusão entre ID tokens e access tokens, o exercício exige um tipo compatível com at+jwt, além das verificações de emissor e audience.
Tornar os limites temporais observáveis
O relógio da fixture é fixo e a tolerância é zero. No instante exp, o token já é rejeitado; no instante nbf, pode tornar-se válido. A ausência de exp e um valor exp em texto são rejeitados neste perfil. A política local acrescenta duração máxima de dez minutos e recusa emissão no futuro. Esses dois limites são escolhas didáticas, não requisitos universais de todos os JWT. Sistemas reais podem permitir pequena tolerância de relógio, mas precisam de justificar o valor e monitorizar sincronização. Aumentar tolerância indefinidamente para resolver um incidente prolonga exposição e pode esconder deriva. Regista relógio observado, categoria de falha e versão da política sem publicar a credencial.
Usar o ensaio para formular critérios de integração
Converte as verificações em critérios de aceitação: assinatura alterada, emissor errado, audience errada, tipo incompatível, expiração, chave desconhecida e claims em falta devem ter resultados definidos. Inclui casos válidos para evitar uma proteção que simplesmente bloqueia tudo. O código é um modelo limitado, não uma biblioteca JWT auditada nem uma implementação completa do perfil. Não cobre todos os casos de parsing, membros JSON duplicados, protocolos OAuth ou obtenção remota de chaves. Num projeto, usa componentes mantidos e revistos, confirma a configuração efetiva e repete os testes nos pontos de entrada relevantes. O valor do laboratório é tornar as fronteiras explícitas e verificáveis, sem transformar uma execução local numa aprovação da arquitetura de produção.
node content/labs/securityx-api-authorization/run.mjs --output /tmp/securityx-api.json
# Synthetic keys and claims only; inspect checks, not real bearer tokens.Uma assinatura válida com aud destinado a outra API é rejeitada, tal como um token expirado no instante exato de exp.
Armadilhas comuns
Decodificação como validação; kid como confiança; ID token como access token; tolerância de relógio sem limite.
Tópicos relacionados: Fronteiras de confiança · Autorização de APIs · Revogação e operação
Uma assinatura válida é apenas uma parte do contrato de aceitação do token.
Referência: JWT Profile for OAuth 2.0 Access Tokens · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17