need to redeploy regularly every few months, it seems the key ids change in jwks.json

[hubsi]

Getting this error every few months needing to redeploy:
stderr | 598a88bc | thread 'main' panicked at 'called Option::unwrap() on a None value', src/jwt.rs:25:10
stderr | 598a88bc | note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
stderr | 598a88bc | {"diagnostic":"instance_error","error":"entered_unreachable","trap":{"trap_code":"wasm unreachable instruction executed","i32_exit_status":null,"display_reason":"wasm trap: wasm unreachable instruction executed"}}

It appears that this is caused by a change of the kid fields in jwks.json leading to a None value after filtering for the (renamed) key_id

Is there a possibility to refresh the jwks.json on a regular basis from the jwks_uri instead of deploying it statically into the well-known folder?

[timwisbauer-contsec]

This seems to happen because the jwks.json file contains public keys for the OIDC provider and are built into the package by the build process. See: https://github.com/fastly/compute-rust-auth/blob/main/src/config.rs#L71

However, these keys are regularly rotated by many providers such as Okta: https://developer.okta.com/docs/concepts/key-rotation/ and tokens can no longer be validated. Okta warns against doing this

Caution: Keys used to sign tokens automatically rotate and should always be resolved dynamically against the published JWKS. Your app might fail if you hardcode public keys in your applications. Be sure to include key rollover in your implementation.

It'd be ideal if the keys could be looked up just before validation to avoid needing to rebuild and deploy the function periodically.

[doramatadora]

Apologies for taking so long to address this properly. v0.4.0 (#39) uses secret store and config store–both now in general availability for Fastly Compute–to decouple configuration from code. This means you can now rotate keys separately from deployments of the service.

Sorry again, we try to do better :)