ASP.NET Core. How can I invalidate JWT-Token after password change

Question

Sorry for my bad English. I'm writing an application in ASP.NET Core using Vue.JS for client-side. For authenticate user I'm using JWT and ASP.NET Identity. I have a method for change the password. But I can't understand: How to invalide token after password change? I want that the user authenticated in another browser will logout after that. Is there a man who haved a problem like this?

Hi, Refer this link [https://stackoverflow.com/questions/31919067/how-can-i-revoke-a-jwt-token] for JWT-Token Revoke — naveenkumar, Jun 14 '19 at 10:12

score 0 · Answer 1 · answered Apr 01 '19 at 16:20

0

You normally don't invalidate JWT's because they are meant to be short-lived access tokens and therefore after the password change, request for new token will prompt the user to reenter credentials.

If you do absolutely need to invalidate the JWT immediatelly after password change - you need to look into Introspection where your backend api essentially has a backchannel to your token issuer and it can then re-validate token every request. This way if you invalidate token at the issuer side - it will reflect on the api side immediately.

answered Apr 01 '19 at 16:20

Vidmantas Blazevicius

4,652
2
11
30

Thansk for an answer. I have a one variant. Can I change a life time of token? – General2001 Apr 01 '19 at 16:23
@General2001 - usually - yes, but it depends on which JWT token provider you are using. – Vidmantas Blazevicius Apr 01 '19 at 16:24
I make everything like here: https://metanit.com/sharp/aspnet5/23.7.php. – General2001 Apr 01 '19 at 16:25
Sorry if I can't to explain more extensively. I started doing this recently. I'm about JWT. – General2001 Apr 01 '19 at 16:27
@General2001 in your example, there is configuration for token lifetime `expires: now.Add(TimeSpan.FromMinutes(AuthOptions.LIFETIME)),` in `AccountController` – Vidmantas Blazevicius Apr 01 '19 at 16:27
An how can I invalidate that? – General2001 Apr 01 '19 at 16:30
Is I understod, I should to generate JWT-Token again? – General2001 Apr 01 '19 at 16:32
You can’t, just set lifetime to like 30minutes or something like that and it will be – Vidmantas Blazevicius Apr 01 '19 at 16:32
Can you show some code, please? I may noob. I will be grateful. – General2001 Apr 01 '19 at 16:36
If I invalide a lifetime of token (set 10 seconds, for example), I'll have to login again (every 10 seconds). I'm right? – General2001 Apr 01 '19 at 18:52

Bryan S. · Answer 2 · 2021-06-27T00:48:56.150

I've been thinking about this and the inability to invalidate a JWT that's already out there may not be built into anything, but is possible.

Here's the narrative: You have an alarm system installed that can be controlled via web and your ex-S/O is logged in to your previously shared account. They are upset and they keep enabling the alarm at random times. If the web app uses JWTs to store session, you could change your password but the JWT your ex possesses will still be usable for a period of time until the timeout is reached.

Solution 1: short timeout. but what if you want to stay logged in for longer periods (such as a password manager)
Solution 2: logout ALL users by changing the Signing Key of your Certified Authority, basically invalidating ALL JWTs across the board. This is still a less ideal route as I'm sure you can imagine.
Solution 3: track the current JWT for each user in your Users table. If the JWT they possess is different from the current one, then they aren't authenticated. If the user logs out, nullify the stored JWT-data in your Users table which would equally unauthenticate JWTs for that user and force a relogin. I'd also recommend storing a bool of "logged in" for the user. DO NOT RELY ON THIS. This would be a value to set to true when they log in, set it to false when they log out, and validate the value is 'true' if they ever pass you a JWT. This will ensure that the moment they logout they are forced to reauthenticate.

Assuming you go with solution 3:

When storing JWT data for this solution, I'm leaning towards not storing the entire JWT because it's rather large text to begin with. Alternatively just store the JWS (JWT Signature) which will make the stored value both smaller and unusable if captured for any reason. Next, it's a hash to begin with so we could just store the last maybe 9 values (9 because int32 max is 2147483647). We just need a bit of uniqueness, not much. Next, we could avoid the string comparison for validating that the JWS passed is the active one if we use regex to pull the integers out of the JWS and again take maybe the first 9 numbers you encounter.

Following this method, and returning to the narrative, if you were to log out your user would be marked as logged out resulting in both yourself and your S/O being required to reauthenticate. (assuming you've changed your password you're golden, otherwise it's time to contact Customer Support) If you were to log back in, you'd get a fresh JWT and a new signature would be stored in the Users table. If your S/O were to try to use the site, they would not be authenticated with the their old JWT and would be forced to sign back in.

Trade-off: If we only store the JWS, or a part of it as I suggested, multiple users can't be signed in to the same account at once. How you feel should feel about that really depends on your app.

I'd say option one, and maybe option two in some rare cases – Tomap Jun 27 '21 at 18:31 — Tomap, Jun 27 '21 at 18:31

ASP.NET Core. How can I invalidate JWT-Token after password change

2 Answers2