Live data from Hacker News

Don't use JSON web tokens for sessions

cryto.net

151–153 of 153 posts

Re: Don't use JSON web tokens for sessions

#151
post #2

I'm working on a personal project and use JWT for sessions. The main reason I did this is that my understanding is that it makes it much easier to implement sessions on mobile apps. Is this true? If so, should I continue using them? If not, why do I think that, and how can I future-proof my API with mobile apps in mind?

Doesn't matter. JWT can be read on the client, but it's not necessary. From a typical client's point of view, the auth token is just a string. Doesn't matter if it's a JWT or a random string. The difference is on the server side — checking a signature vs. looking up in a database.

Re: Don't use JSON web tokens for sessions

#153
my approach: after authentication i'm generating a JWT and send it to the client that stores it in LocalStorage. On the server side I'm using a memcached database that stores a key-value-pair (JWT and some config stuff that shall not be visible on the client side..) for 30 minutes and then deletes it. The JWT is sent with every client request in the Authorization header. A function checks if there is any key-value-pair in the memcached database that matched the JWT (key) and if that JWT is valid. After that it continues or denies the request. The client requests a new JWT after 29 minutes. If the client is offline and doesn't request that new JWT, the old JWT is killed after 30 minutes, anyway. I can't see any other attack vector than XSS - which I'm trying to avoid as hard as I can. But lets face it: IF you have a XSS problem, then you'll have it anyway, with JWT or without. If someone has full access to the JavaScript of your website, he/she can capture any authentication data you are going to send over the wire, unless you use cookies (where you'll have the CSRF problem..).

SO, I think it's pretty safe if you get your XSS protection right.

Opinions? Thank you :)

Post reply on HN