JWT signing key stuck in browser cache. Bug?

We are experiencing an interesting challenge when rotating the JWT signing key.
When we manually initiate the JWT signing key rotation using Postman and POST to the following URL:

{{url}}/api/v1/authorizationServers/{{authorizationServerId}}/credentials/lifecycle/keyRotate

The POST works fine and after the “keyRotate” call succeeds, we can use the following GET call and see that the old “ACTIVE” key is now “EXPIRED” and a new “ACTIVE” key is available:

{{url}}/api/v1/authorizationServers/{{authorizationServerId}}/credentials/keys

So far so good, but the problem occurs with the Angular application we are using as a client.

This issue can be easily reproduced using the Angular “okta-hosted-login” sample at: GitHub - okta/samples-js-angular: samples-js-angular

Recreating the problem is easy.

  1. Login successfully to the Angular application (using either Chrome or Edge on Win10).
  2. Rotate the signing key via Postman.
  3. Now the browser(s) are broken.

It isn’t obvious at first, but if you Logout and close the browser (even restart the PC if you want) and try logging in again it fails.

Using the browser Developer Tools and clearing the Local Storage does no good, since the stale signing key come right back with the old value.

Troubleshooting indicates the browsers have the old version of the Okta signing keys cached in the browser and they don’t go away.

To unstick the key you can manually clear out the browser cache (for Chrome use): Settings/Privacy & Security/Clear browsing data/Images and Files. - Clear All.

The question is, how can we make this work without having to manually clear the browsers “Images and Files”?

Without this fix, the browser is unable to successfully log back into the Angular application.

I’m pretty sure I’m not the first person to have this issue.

How can I solve this challenge?

Can you file a GH issue against the Auth JS SDK (the underlying library that’s used by the Angular SDK) for this?