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 I’m curious why that might be bad practice. Is only bad when used instead of a blacklist / whitelist approach?
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 I’m curious why that might be bad practice. Is only bad when used instead of a blacklist / whitelist approach?
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.