Gerador JWKS EC (P-256/P-384/P-521)

JWKS com chaves de curva elíptica

JWKS significa JSON Web Key Set — um documento JSON contendo uma ou mais chaves públicas usadas para verificar assinaturas de JWT. É definido pela RFC 7517 (JWK) e pela RFC 7518 (JWA, os algoritmos), e virou o formato de distribuição de chaves públicas em OAuth 2.0, OpenID Connect, auth mobile e tokens de ServiceAccount do Kubernetes.

Anatomia de um JWK EC

Um JWK de curva elíptica carrega o ponto público de uma chave EC. A curva é identificada pelo campo crv — tipicamente P-256 (secp256r1), P-384 ou P-521 — e as coordenadas x e y são inteiros big-endian codificados em base64url.

{
  "kty": "EC",
  "crv": "P-256",
  "kid": "key-2026-01",
  "use": "sig",
  "alg": "ES256",
  "x": "base64url-x-coord",
  "y": "base64url-y-coord"
}

Obrigatórios: kty, crv, x, y. Opcionais mas recomendados: kid (key id para rotation), use (sig ou enc), alg (o algoritmo JWA) e opcionalmente x5c para cadeias de certificado X.509.

O endpoint JWKS

Um JWKS é apenas um objeto JSON com um array keys, tipicamente servido em /.well-known/jwks.json. Os clientes buscam uma vez, cacheiam pelo Cache-Control: max-age=3600, acham a chave certa casando o kid do header do JWT contra o JWKS, e verificam a assinatura.

Algoritmos ECDSA

• ES256 — ECDSA sobre P-256 com SHA-256. A escolha mais suportada e default no OIDC.
• ES384 — ECDSA sobre P-384 com SHA-384. Maior margem de segurança, assinaturas maiores.
• ES512 — ECDSA sobre P-521 com SHA-512 (atenção: curva de 521 bits, hash de 512 bits).
• EdDSA — Ed25519, RFC 8037. Ainda mais rápido e menor, mas com suporte menos universal.

EC versus RSA

Chaves de curva elíptica são dramaticamente menores para o mesmo nível de segurança: uma chave EC de 256 bits equivale a uma RSA de 3072 bits. Assinar é mais rápido, assinaturas são mais curtas (~64 bytes para ES256 vs ~384 bytes para RS256), e o payload do JWT continua enxuto. Para sistemas novos, EC é o default moderno; RSA fica para interoperabilidade legada.

Rotação de chaves na prática

Rotação é a razão de o JWKS publicar um conjunto ao invés de uma única chave. Fluxo típico: gera uma chave nova com kid novo, publica antiga e nova no JWKS, assina JWTs novos com a chave nova, espera os JWTs antigos expirarem, e remove a antiga. Faça rotation no mínimo trimestralmente, mais frequente se houver suspeita de comprometimento. Mantenha a chave privada em hardware (HSM, KMS, TPM) sempre que possível.

Onde isso aparece em produção

Auth0, Okta, AWS Cognito, Google Sign-In, Apple Sign In, Microsoft Entra, Firebase Auth — todo provedor de identidade grande publica um endpoint JWKS. Tokens projetados de ServiceAccount do Kubernetes são verificados contra um JWKS do cluster. Fluxos de auth mobile e IoT dependem de JWKS para verificação offline.

Perguntas frequentes

EC ou RSA — qual escolher? EC é a escolha moderna: assinatura mais rápida, chaves e assinaturas menores, segurança equivalente. Use RSA só se precisar integrar com sistemas antigos que não suportam ES256.

O kid é obrigatório? Não pela RFC, mas fortemente recomendado — é como os clientes escolhem a chave certa durante a rotation. JWKS com uma única chave imutável não escala.

De quanto em quanto tempo o cliente deve atualizar o JWKS? Respeite o header Cache-Control, mas também faça refresh on-demand sempre que um JWT referenciar um kid desconhecido. Padrão comum é "cache 1 hora, força refresh em miss".

Posso incluir a chave privada no JWKS? Nunca — JWKS é para chaves públicas. Mantenha a chave privada em um secret manager, HSM ou KMS, e só a chave pública correspondente vai para /.well-known/jwks.json.