Hacker News Reader

Comment by caiob | Hacker News Reader

Why not just "invalidate" the client? At best, you're making your application "safe" for 900ms or whatever the expiry date is.

View on HN

What do you mean by "invalidate the client"?

Seriously?

I would like to know what you mean. “Invalidating the client” seems almost nonsensical since you don’t control the client.

You do control what clients (think client_id/secret) can use your APIs. Don't you? You figure it out from there.

No. 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.

Classic hostility on HN. I'm out, I'll go find my tribe.

Nowhere 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.

No, you don't control the client. The attackers do.

Yes, seriously. How to invalidate is exactly what is being discussed.

I 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?

Reply on news.ycombinator.com