no applicable key found in the JSON Web Key Set

jose (JavaScript) — JWKSNoMatchingKey, code ERR_JWKS_NO_MATCHING_KEY

O que significa

O jose percorreu o conjunto de chaves (JSON Web Key Set) que você passou e não encontrou nenhuma chave que possa verificar este token. Uma chave só se qualifica se todas estas condições forem atendidas: o `kid` dela é igual ao `kid` do cabeçalho do token (quando o token tem um), o `kty` combina com o `alg` do token, o `alg` dela (se presente) é igual ao `alg` do token, o `crv` corresponde (P-256 para ES256), `use` está ausente ou é `"sig"`, e `key_ops` (se presente) inclui `"verify"`. Nenhuma operação criptográfica foi executada — a falha está na seleção da chave.

Por que acontece

• O emissor rotacionou a chave de assinatura

  comum

  Os tokens novos trazem um `kid` novo que o conjunto de chaves em cache ou fixo no código ainda não contém. Esta é a causa mais frequente e costuma começar no minuto exato de uma rotação; serviços reiniciados depois dela funcionam, os iniciados antes falham.

• O conjunto de chaves pertence a outro emissor ou ambiente

  comum

  Uma URL de JWKS de homologação em produção, o JWKS de outro locatário ou um conjunto de chaves copiado da documentação. Todos os `kid` parecem plausíveis, nenhum corresponde.

• Os metadados da chave contradizem o token

  ocasional

  A JWK tem `alg: "RS256"` enquanto o token é ES256, ou a chave EC está na P-384 enquanto o token usa ES256 (que exige P-256). O jose ignora essas chaves mesmo quando o `kid` corresponde, porque os metadados da JWK existem justamente para impedir que uma chave seja usada com outro algoritmo.

• A chave está marcada para criptografia

  ocasional

  Uma chave publicada com `use: "enc"` ou com `key_ops` sem `"verify"` não é uma chave de verificação de assinaturas. Alguns provedores publicam os dois tipos no mesmo conjunto; só as chaves `sig` conseguem verificar tokens.

• Uma cópia local do JWKS nunca foi atualizada

  ocasional

  O `createLocalJWKSet` usa as chaves que você passa, para sempre. Se o conjunto veio de um arquivo ou de uma variável de ambiente no momento do deploy, ele fica desatualizado, sem nenhum aviso, na próxima rotação.

Como corrigir

1. 1.

   Comparar o kid do token com as chaves publicadas

   Decodifique o cabeçalho protegido e liste as chaves publicadas com `kid`, `alg`, `kty`, `crv` e `use`. Se o `kid` não estiver no conjunto, trata-se de uma rotação ou do conjunto de chaves errado; se estiver, examine os campos de metadados.

   # kid and alg the token asks for
   python3 -c 'import base64,json,sys; h=sys.argv[1].split(".")[0]; print(json.loads(base64.urlsafe_b64decode(h + "=" * (-len(h) % 4))))' "$TOKEN"
   # kid, alg, kty, crv, use of every key the issuer publishes
   curl -s https://issuer.example.com/.well-known/jwks.json | jq '.keys[] | {kid, alg, kty, crv, use}'

2. 2.

   Buscar o JWKS do emissor em vez de fixar chaves

   O `createRemoteJWKSet` guarda as chaves em cache e busca o conjunto de novo quando um token cita um `kid` que ele ainda não viu; assim, as rotações são incorporadas automaticamente, sem aceitar chaves arbitrárias.

   import { createRemoteJWKSet, jwtVerify } from "jose";
   
   // Fetches the JWKS, caches it, and refetches when a token names an unknown kid
   // (at most once per cooldownDuration, 30 s by default).
   const jwks = createRemoteJWKSet(new URL("https://issuer.example.com/.well-known/jwks.json"));
   const { payload } = await jwtVerify(token, jwks, {
     algorithms: ["ES256"],
     issuer: "https://issuer.example.com",
   });

3. 3.

   Publicar chaves com metadados consistentes

   Se o emissor for seu, garanta que cada chave de assinatura tenha um `kid` único, `use: "sig"` e um `alg` e um `crv` que correspondam aos tokens que ela assina. Publique a chave nova antes de começar a assinar com ela.

   {
     "keys": [
       { "kty": "EC", "crv": "P-256", "kid": "2026-10", "use": "sig", "alg": "ES256",
         "x": "…", "y": "…" }
     ]
   }

← Ver toda a base de erros de assinatura