JWT vs Sessions

Question

I have a PHP application, currently it is highly reliant on Sessions. I am trying to remove most , if not all, session usage from it.

When it comes to logging a user in. I have a few choices,

1. continue to use sessions to store basic user data.
2. generate my own cookie based token, pointing to an ID of info stored in memcache with basic user data in it, to verify the user
3. generate JWT token, stored in cookie, and used for storing an ID pointing to information in memcache to verify user.

Basically , I am trying to avoid issues like session hijacking etc. but I am not sure implementing a JWT system will be as helpful as I first thought.

There is much written it seems about the pros of JWT, but equally, plenty written about "dont use JWT for sessions"

Given that I am not planning on storing actual user data in the JWT token, just an ID, is there much advantage to this over a standard PHP session ID?

Main advantage I see is that I can ensure its not tampered with, but would still suffer from been able to hijacked given that it is stored in a cookie?

Ensuring the cookie is HTTP_Only would help no doubt in some aspects.

So from a security point of view, what is the more trusted, less prone to security issues , method of storing what is basically a session ID stored in another format.

Answer 1

You have to ask yourself what you try to protect against (you mentioned issues like session hijacking) and in what environment.

IF you want to only store a session identifier on the client side, JWT does not give you anything, that is not already provided by the typical cookie-based sessions.

The problem that is solved by JWT is that session data can, if your service is hugely popular, put a strain on your server. With JWT, the session data is stored on the client-side, because of which, the server does not need to keep track of state (which is why some people say that JWT is 'stateless'), thereby offloading the load to the client. Keeping state on the client side does however introduces a lot of extra complexities.

Keeping state on the server-side is the classic pattern. This pattern is well understood and the various issues have, over time, been straightened out. Implementing a cookie-based sessions is quite straight forward. Cookies also come with some extra protective measures compared to 'plain' headers, such as the http_only and secure_only flags.

The security people are, generally speaking, quite cautious with adapting shiny new implementations; they like to place their money on well understood, time-tested patterns. So, while JWT are quite fashionable at the moment, that does not make them a better security solution. For your typical web-application, I would, without a doubt, advice using cookie-based sessions.

Answer 2

JWTs are not designed for session management, yet they are quite capable if you can live with a few trade-offs (no logout, no idle-timeout, no re-authentication, etc.) To understand what you can and cannot do with JWT sessions I recommend reading this article.

Given that I am not planning on storing actual user data in the JWT token, just an ID, is there much advantage to this over a standard PHP session ID?

The advantage is that of performance and simplicity.

Performance: on high traffic, distributed sites, it makes sense to avoid the call to the "DB" which validates the session. With JWT you can do everything in memory, given that you include user data within the token. If only the ID is included and you need the DB call to fetch user details, there is no real benefit in terms of performance.

Simplicity: there are cases where you are only a "middle-man", as in your application has no state by itself. In these situations, keeping the above limitations in mind, it makes sense to avoid keeping a state just for the authentication sessions. Your use-case does not seem to fit this scenario.

Main advantage I see is that I can ensure its not tampered with, but would still suffer from been able to hijacked given that it is stored in a cookie?

True, w/ JWT if you send the data down to the client it is integrity protected. The client cannot modify any of it without invalidating the token, although it can read it. This may or may not be a problem, depending on your use-case (you can also encrypt JWTs...) If only the ID is included, you do not realize any benefits of JWT.

If the JWT is stored in a cookie, you need to deal with everything a cookie-based session handling requires. Use the Secure and HttpOnly flags to prevent leaking your token. You also need to deal with CSRF. Use anti-forgery tokens or the SameSite flag on cookies. More on cookies.

In a classical cookie-based session handling you only send an opaque ID, so you don't expose any data by design.

In the end, it comes down to trade-offs. In simple scenarios, I almost always recommend cookie-based session handling.