-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JWT: support ALB token format #191
Comments
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
headerThe text was updated successfully, but these errors were encountered: