RequestAuthentication: Inexplicably solve error "Jwks doesn't have key to match kid or alg from Jwt"


I have been trying to setup RequestAuthentication but am getting the following error " Jwks doesn’t have key to match kid or alg from Jwt " .

My jwksUri is correct with the following config:

kind: RequestAuthentication
  name: order-composite-request-authentication
  - forwardOriginalToken: true
    issuer: http://auth-server:80
    jwksUri: http://auth-server.demo.svc.cluster.local/oauth2/jwks
    matchLabels: order-composite

When I launch the containers and try to query my service I get:

$ curl -ks -H "Authorization: Bearer $ACCESS_TOKEN"  -i
HTTP/2 401 
www-authenticate: Bearer realm="", error="invalid_token"
content-length: 50
content-type: text/plain
date: Fri, 10 Dec 2021 11:11:13 GMT
server: istio-envoy
x-envoy-upstream-service-time: 1

Jwks doesn't have key to match kid or alg from 

Without changing anything, after a random amount of time (usually minutes) I can see in the logs that my cached JWT public key is updated:

2021-12-10T11:13:30.523930Z	info	model	Updated cached JWT public key from "http://auth-server.demo.svc.cluster.local/oauth2/jwks"

After the cache is updated I can finally query my service:

$ curl -ks -H "Authorization: Bearer $ACCESS_TOKEN"   -i
HTTP/2 200 
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
cache-control: no-cache, no-store, max-age=0, must-revalidate
pragma: no-cache
expires: 0
strict-transport-security: max-age=31536000 ; includeSubDomains
x-frame-options: DENY
content-type: application/json
content-length: 60
date: Fri, 10 Dec 2021 11:26:06 GMT
x-envoy-upstream-service-time: 33
server: istio-envoy


I don’t understand how the cache is invalid in the first place…

Is there a way to force refresh or ignore that cache?
Can I make istio refresh the authorization policies?



Were you able to resolve the issue?

I have been seeing the same behaviour and I was not able to fix the issue by restarting the pods (and sidecars).

1 Like