1

I have been thinking to try out JWT as an alternative to the old session based authentication for performance reasons (i.e. no additional SQL lookup for session id in database just to get the user id for each and every HTTP request) and usability reasons (JWT is gonna be used in HTTP headers instead of cookies so that my app can be used as RESTFUL API and accessed by non-browser clients like mobile apps, also adding JWT in HTTP headers eliminates the danger of CSRF). Since the payload is signed with a secure HMAC like SHA256, it's nearly impossible to forge the payload. Additionally, the user id itslef isn't really a secret and is used publicly by the app.

I am thinking of using a payload that is something like this:

{
  id: "1234abcd",
  iat: 1522779638
}

where iat is a unix timestamp at which the JWT was created and this can be used to expire the JWT message and also harden the security by randomizing the hash for the same id.

My question is, assuming that I am going to apply strict HTTPS connection for my app in production, is using this unencrypted payload secure enough to verify user's identity and initiate unsafe methods like POST methods (e.g. follow a user, unfollow a user, etc...) that's as secure as the session based authentication? Do I need to encrypt the payload using something like AES-192 or AES-256 just to be more sure?

1

This seems as being enough to authenticate the user and secure the token in transit. However, the problem could be that with this system, you would not have a good way to revoke such a token. So if the token is stolen, it can be used forever. You may want to have a way for user to revoke these tokens. There are many scenarios where token could be stolen, from malware through stolen phone to logging in on insecure PC let's say in an internet cafe.

One possibility would just be to add a single "not-before" column to the users table and refuse tokens with iat lower then that. So the user could revoke all previously issued tokens by setting this column to the current timestamp. This would require access to the database, but only to the users table using ID which you will probably want to do anyway.

  • Yes, iatentry is also going to be used for invalidation if it's older than 6 months or something. So it's not just here for randomizing the hash for same id. Excluding the possibility of stealing the JWT since also the session id can be stolen by various means, is this unencrypted payload enough to make an equally secure authentication as the session id method? – pls no May 6 '18 at 16:44
  • I mean, is encrypting the payload is some sort of useless in this case? – pls no May 6 '18 at 16:45
  • @plsno I am not sure what you mean. Encrypting the token in addition to HTTPS is useless. If HTTPS is broken, the token can be used whether encrypted or not. However, it can't really be used without HTTPS if that is what you are thinking. – Peter Harmann May 6 '18 at 16:48
  • I understand that the whole HTTP message is encrypted at the TLS level, I meant by encrypting the payload, that it can look like a random token to whoever decode the JWT, so that nobody can understand that I am just using the user id directly as means of authentication and not some random token that acts as a session id. I hope you can get what I mean since my English isn't that good so I apologize. – pls no May 6 '18 at 16:52
  • 2
    @plsno You can go for it. IMO won't help with security much, because when the attacker sees the encrypted token, he does not care what it is or how it works, he can just use it. But as I said, it shouldn't hurt either. – Peter Harmann May 6 '18 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.