How to gracefully handle an auth key change

We are securing environments (generating new auth keys per env) and planning for what to do when there is a breach of some sort.

In the event of some type of data breach, from my understanding, with JWT it’s best to regenerate the secret key, which should invalidate any existing tokens.

But the GetAccessToken endpoint doesn’t seem to handle this very well (it returns a “Value cannot be null.
↵Parameter name: jwtPayload”). To test, I logged in as a normal user, with a 15 second bearer refresh timer. Then stopped the server, changed the auth key, then started the server. The next requests with our SS js client got the normal Unauthorized response, which triggered a GetAccessToken (as expected).

But it returns this “Value cannot be null” error. Is there any better way to gracefully handle this?

GetAccessToken should throw “Token is invalid” from this commit. If preferred the ErrorMessages.TokenInvalid message can also be overridden.

This change is available from the latest v5.5.1 that’s now on MyGet.

1 Like

Fastest turnaround time ever, thank you!

1 Like