fix: Adds Cache-Control headers to JWKS endpoint requests#1590
Open
aemard wants to merge 1 commit into
Open
Conversation
Prevents stale key issues by adding Cache-Control headers to force fresh JWKS key fetches from the authorization server while preserving application-level caching in localStorage.
Contributor
|
@aemard Can please send a signed CLA to cla@okta.com |
Author
|
@jaredperreault-okta CLA signed and sent to cla@okta.com |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR adds
Cache-Controlheaders to JWKS endpoint requests to ensure fresh keys are always fetched from the authorization server instead of potentially stale cached versions from HTTP-level caches (e.g., browser cache, proxies, CDNs), while preserving application-level caching inlocalStorage.What Problem Does This Solve?
When keys are rotated at the authorization server, HTTP-level caching can cause the SDK to continue using stale keys, which may lead to token validation failures.
Changes Made
Cache-Control: no-cache, no-store, max-age=0headers to JWKS endpoint requestslocalStorageremains unaffectedTesting Done
Security Impact
Positive: Reduces the window of vulnerability when keys are rotated by ensuring fresh keys are always used for token validation.