2

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.

  • I don't understand the difference between using sessions and storing information keyed by id - which is stored in a cookie by whatever means - in memcache. Isn't this exactly the same thing? Can you clarify? – Pascal Oct 31 '16 at 17:17
  • If you don’t have any session data you can also use the JWT to contain a username only and go stateless. That does complicate logouts, however. – eckes Feb 19 at 7:17
6

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.

1

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.

  • The advantage you speak of is only possible if user data is stored in the JWT. If there is only an ID in the JWT, this answer is wrong. – Josef Feb 19 at 9:00
  • Thanks for pointing that out. I updated the answer to address the "only ID in the JWT" scenario. – Daniel Szpisjak Feb 19 at 9:33

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.