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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.