Today I read this article here at dev.to because it is, in my opinion, a topic everyone should care about.
The author explains well all the points...
For further actions, you may consider blocking this person and/or reporting abuse
Hi. For most implementations where the size of the table doesn't usually exceed 100 records, I would run cleanup at the same time I do querying. Yes, I would be violating the idempotency of the "Get" nature of the operation in favor of a simplified architecture.
If you don't like that, or if the average number of records makes it so that the invested time in cleanup definitely takes a toll out of using the table values, then spin up a background service that does this cleanup every X minutes.
Also take the opportunity to clean up every time you globally invalidate, and every time a per-user invalidation takes place. Global invalidation cleanup is trivial (empty the table, then just leave the global record); per-user invalidation cleanup would be a DELETE statement with the WHERE condition set to what the paragraph describes as being the condition.
Hey! I like this approach, but I just can't figure out how to manage multiple tokens. So, for my understanding, this is the situation I have in mind:
If the "BlTimestamp" is set to the date when User X logs out in Browser A, then everything's fine if that user continues in that browser.
But if User X opens up Browser B just a few minutes after logging in using Browser A, then I find this problem:
After the User X logs out in Browser A, the requests in Browser B would be denied because I would use the most recent invalidation date (when the user logs out), which should invalidate only token for Browser A.
Now, if the "most recent [token invalidation]" were to be the "exp" of token for Browser B, then any request after User X logs out Browser A, would no longer be unauthorized.
I'm not saying the article is wrong, I'm just confused here.
Hello!
Logging out from a browser window should be limited to forgetting the token being used by that window and invalidation should not come into play.
This invalidation system is not meant to support log-out processes. To log out, remove the token from session storage. If you are passing the token in a cookie, then delete the cookie. That should be what the log-out process does.
Use this invalidation system to "log out from all devices" scenarios, or "user X's credentials were compromised, so invalidate all tokens for user X".
Let me know if this clarifies the question.
Question you might ask next: How can I have per-tab/browser window cookies? Not easily. I would generate a random GUID on load, then save it to session storage. This GUID would become part of the log-in data. Then the server sends a cookie whose name is/includes this GUID. Never tried this myself. It most certainly sounds like an interesting challenge.
Oh, now I got you. It's clear. It makes complete sense in cases where I want to invalidate all tokens from a user.
I'll see how to deal with the question you mentioned. Thank you!
Alright I might be the only one requesting for this but yeah, I want to see the laid out implementation. I will appreciate it.
Node.js, please.
Hi! I have updated this entry showing the core logic of the
iatcheck. If, like the note below the code snippet says, things don't make complete sense to you, wait for the upcoming article showing the entire project.Thank you for the update. Better understood now.
And yes, I'd love an upcoming article detailing the raw implementation of the service.
Ciao
Ok, the full tutorial in NodeJS + Express is out.
Invalidating JSON Web Tokens (JWT): NodeJS + Express
José Pablo Ramírez Vargas ・ Dec 11 ・ 13 min read
Brilliant technique. Thanks for the article
No problem. I'm now exploring
single-spa, if you are interested.I'm interested. Any link to where you are doing that (github or articles)?
This series @ hashnode.com, where I hold my blog.
I am following this approach when user change his password so I wanted to user should be logout from all the other devices so its work very well in those scenario when we want to invalidate JWT token.
Hi. This is a great article, it is very simple way to blacklist the token, but, what if I have multiple device or platform, let say mobile, desktop, and web, and i want to logout from web, it would be logout from all other device, is it correct ?
As it is shown here, yes. But the beauty of it, is that you can further categorize the blacklisting process. Add an extra column to specify the token types that are to be invalidated. I would used a bitwise enumeration: 1 = web, 2 = desktop, 4 = mobile, etc. If I were to invalidate, I would include the type or types of token invalidated: 3 would mean web + desktop; 7 would mean all (web + desktop + mobile). You probably get the idea.
yeah i got the idea. Thankyou, i love this approach, and this is more eficient approach so far (for jwt auth)
If user want to login with Incognito, and normal tab of browser. We will generate 2 JWTs for him. In my db, we only check the latest JWT which will provide user 401. But expected was 200 because user has loggedIn with two different places. Then, In this case it will fail.
If I am understanding correctly, you are saying: If a user users 2 browsers (or one in regular mode and one in incognito mode), the user will have been issued 2 tokens. Yes, so far so good.
Then you say we invalidate the user's tokens based on creation time, which is what the article is about. For some reason you seem to disagree with both tokens being invalidated. This depends on the chronological order of events, but if you are thinking the following, then yes, both tokens get invalidated:
With this order of events, both tokens were invalidated. Why are you expecting one token to work?? I guess that's the part I don't understand.
UPDATE: Oh, ok. I re-read your answer. For some reason you are thinking incognito mode is special or something? Why do you think the browser used needs to have special treatment? Why do you think one token has to survive just because it came from X or Y browser in N or M mode? To me, that should not matter at all.
Hi
Lets take example
browser A : User receives a valid token, TokenA with userId 123 and timestamp - 2022-12-04T19:27:00Z.
DB call :
{
userId : 123,
timestamp : 2022-12-04T19:27:00Z
}
Same User gone for second browser to login again
browser B : User receives a valid token, TokenB with userId 123 and timestamp - 2022-12-04T20:27:00Z.
DB call :
{
userId : 123,
timestamp : 2022-12-04T20:27:00Z
}
As per your blog the browser A will logout with the api call which took the JWT have timestamp "2022-12-04T19:27:00Z" because the latest one is with the timestamp - "2022-12-04T20:27:00Z". But the user has not logout from any of the browser which will effect the user experience as he logout without any actual logout performed by the user.
How we can support multiple login of the same user with different browser or laptops etc.
Hi. For some reason I missed this comment. Apologies.
You seem to be thinking that issuing a token automatically invalidates previous tokens. This is only true if you program your system to work like this. At no point in the article do I say that the act of issuing a token necessarily invalidates all previous tokens for the user. I guess that's the misunderstanding we have here.
To me, if a user wants to have two windows open, then by all means, have them open. I'll gladly issue two independent tokens as long as the user can properly authenticate from both browser windows.
Yes, Iat check is a very good approach
You could make an example using ASP.NET what do you think?
Hello. I'll try to make some time for this, but I'm currently a bit swamped. Might take some time. If you're in a hurry, best to study the NodeJS + Express example and apply the same logic in C#.
Great article. Please, can you provide an example in PHP? Thanks.
Hello Luís! I will have to let you down on this one. I don't do PHP. My skillset does not include PHP. 😢
Well. Thank you very much for your article. 🙏🏽
Interesting idea 👍🏽, will try it out and provide feedback