Open CaerusKaru opened 6 months ago
Support fetching the JWKS key set from a remote endpoint, instead of from a local file or inline value
I don't think we should support this. The reason being that it means services need to block on startup, waiting for fetching of the JWKS to complete. If the endpoint is unavailable for some odd reason, your service can't go live.
Please just write a Kubernetes cronjob that fetches the JWKS and stores it in a configmap.
https://stackoverflow.com/a/71662405 shoes how to update a ConfigMap from a pod.
We are not using k8s. We are using ECS. This option is not available to us.
Further, the JWKS fetch would not block service startup. As I said in the description, the fetch needs to happen dynamically per token, since the key value is embedded in it.
Then schedule a lambda or something. AWS must have some kind of facility to periodically fetch a URL and store it somewhere.
The edit of the above comment is more important in the context here: the AWS JWKS endpoint is not static, it is dynamic, and (possibly) changes with each token passed, but can be cached after request.
AWS Application Load Balancers (ALB) are... special. While they are compliant with the OIDC specification, the resulting token doesn't follow the expected format. Instead of returning a JWT in the
Authorization
header, it returns it in thex-amzn-oidc-data
header. And instead of publishing one consistent JWKS key set file, it publishes one per region, and returns the key ID (kid
) as part of the payload of the token, to then be retrieved dynamically, on the fly[1].So, the ask is two-fold:
Authorization
header