You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once a JWT is issued, it generally will be valid until expired or the secret used to generate the token changes. Generally, changing the secret may be very disruptive as it would effectively revoke all outstanding tokens.
You have two other options that come to my mind:
Use user based secrets. This would allow you to revoke a secret for a single user. Perhaps you could query your DB and build a value that is based upon the secret.
Use custom claims. This would require you to create some sort of a one-way hash that uses the password to generate a value (Claim.setup), which you would then need to verify on every request (Claim.verify). One potential downside with this approach is that I do not believe those methods are awaitable. This might cause difficulties with your design if you need to read from an async DB client.
It should be noted that both of these solutions turn your JWT into being stateful, that it so say they require the existence of some state on your application to be verified. I am not saying this is a bad thing. Every application has its own needs. Rather, I want to point out that it does mean that the token can no longer be either verified or denied just by inspecting it. Some further information or operation is needed.
Hi
After the client reset the password, the previous JWT can still be used. What should I do
The text was updated successfully, but these errors were encountered: