OAuth login panics (jsonwebtoken 10.4.0 CryptoProvider) on v0.6.0 -> callback fails as 'Invalid or expired OAuth state' #60

Closed
opened 2026-06-08 16:53:42 +00:00 by mik-tf · 0 comments
Owner

On a freshly provisioned tester running hero_proxy v0.6.0, the forge OAuth login completes the redirect but the callback returns 'Invalid or expired OAuth state' in the browser. The proxy log shows a panic on every callback: thread 'tokio-rt-worker' panicked at jsonwebtoken-10.4.0/src/crypto/mod.rs:125: Could not automatically determine the process-level CryptoProvider from jsonwebtoken crate features. Call CryptoProvider::install_default() before this point, or make sure exactly one of the 'rust_crypto' and 'aws_lc_rs' features is enabled. So the JWT verify in the OAuth callback (the forge OpenID id_token) panics the worker because jsonwebtoken 10.x has no crypto provider installed, and the failed verify surfaces to the user as an invalid state. The gateway route, the gate seed, and the forge redirect all work; only the callback's JWT step fails. Verified live: the proxy stayed up through the whole login (no restart), so it is not a state, cookie, or timing issue. Fix: install a default crypto provider at startup before any JWT operation (rustls aws_lc_rs or ring), or pin the jsonwebtoken features to exactly one of aws_lc_rs or rust_crypto. This blocks login completion for every tester on v0.6.0, so it is high priority for sandbox onboarding. Likely a regression from the jsonwebtoken 9 to 10 bump (older testers using the previous proxy still log in).

On a freshly provisioned tester running hero_proxy v0.6.0, the forge OAuth login completes the redirect but the callback returns 'Invalid or expired OAuth state' in the browser. The proxy log shows a panic on every callback: thread 'tokio-rt-worker' panicked at jsonwebtoken-10.4.0/src/crypto/mod.rs:125: Could not automatically determine the process-level CryptoProvider from jsonwebtoken crate features. Call CryptoProvider::install_default() before this point, or make sure exactly one of the 'rust_crypto' and 'aws_lc_rs' features is enabled. So the JWT verify in the OAuth callback (the forge OpenID id_token) panics the worker because jsonwebtoken 10.x has no crypto provider installed, and the failed verify surfaces to the user as an invalid state. The gateway route, the gate seed, and the forge redirect all work; only the callback's JWT step fails. Verified live: the proxy stayed up through the whole login (no restart), so it is not a state, cookie, or timing issue. Fix: install a default crypto provider at startup before any JWT operation (rustls aws_lc_rs or ring), or pin the jsonwebtoken features to exactly one of aws_lc_rs or rust_crypto. This blocks login completion for every tester on v0.6.0, so it is high priority for sandbox onboarding. Likely a regression from the jsonwebtoken 9 to 10 bump (older testers using the previous proxy still log in).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_proxy#60
No description provided.