3 ms·
Why not just "invalidate" the client? At best, you're making your application "safe" for 900ms or whatever the expiry date is.
by caiob 8y ago
Why not just "invalidate" the client? At best, you're making your application "safe" for 900ms or whatever the expiry date is.
- detaro 8y agoWhat do you mean by "invalidate the client"?
- caiob 8y agoSeriously?
- dpark 8y agoI would like to know what you mean. “Invalidating the client” seems almost nonsensical since you don’t control the client.
- caiob 8y agoYou do control what clients (think client_id/secret) can use your APIs. Don't you? You figure it out from there.
- dpark 8y agoNo. The discussion here is about using JWT for sessions with web clients. If you’re registering a dedicated client id and secret for each web client, they you’re doing something wrong. If you’re doing this and then also using JWT, then you’re doing something really bizarre, and still wrong. Id/secret pairs can make lots of sense for integrating partner services with your API. They make no sense for web clients, where you should be authing a user and not a client.
- caiob 8y agoClassic hostility on HN. I'm out, I'll go find my tribe.
- dpark 8y agoNowhere was I hostile. I answered your comments politely and clearly. You were arrogant and condescending but you apparently don't actually know what you're talking about. Please do go find your tribe of condescending devs with fragile egos.
- mc_mike 8y agoNo, you don't control the client. The attackers do.
- bradenb 8y agoYes, seriously. How to invalidate is exactly what is being discussed.
- drinchev 8y agoI bruteforce a password for your JWT-enabled app. Then I have a token. Copy the token from my browser ( usually just open Network tab at the inspector and copy the headers for the request ). Then I store the token at my server and make it execute a request to the app on intervals to prevent from expiring ( reissue ) the token. How can you invalidate my server now?