re: Simple Intro to JWT Basics VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Great post. I have a QQ. In the the “Avoiding State” section, it seems like you don’t like the idea of changing the secret to invalidate JWTs, and ...
 

Thanks! To answer your question, one of the primary reasons is that it leads to a bad user experience. If I change my server secret, it indiscriminately invalidates all circulating tokens, regardless of when they are created. If I'm a user, and I happened to have logged in just 20 seconds prior to a dev doing this, I'm going to be confused and maybe a little aggravated that I'm suddenly logged out again.

There are legitimate reasons to do this; if a secret key is leaked, you absolutely need to change the server-side key ASAP.

My problem with this method is when it is used as more of a crutch to avoid implementing a more robust session-based approach. At that point, the use of it, at least in my mind, is really a symptom of your system design not matching what is needed.

I try not to be opinionated about these things, but definitely adhere to the idea of "use what is best for your needs".

 

I see, that makes sense. It's better to change the key only if you actually want to revoke all user tokens. If you only want to revoke just some tokens, a different solution makes for a better user experience. Thanks.

code of conduct - report abuse