When you’re building a service, you need to ensure sessions correctly.
It’s why I still prefer server-side sessions because I want the best security for my users.
I’ll explain to you about 4 vulnerabilities …
Replay attacks
With client-side sessions, it’s impossible to invalidate a session (just one example).
When logging out, a new cookie is sent with logged-out session data.
However, as the server doesn’t maintain a state about sessions, it will still accept the old, logged-in cookie until it expires.
One could set very small expiration times to mitigate this, but this would force users to re-login frequently.
The best way to maintain long expiration times while still having secure logouts is server-side sessions.
Cookie size and data
When you’re using client-side sessions, you save all inside cookies or local storage and when you’re saving the whole session, it’s becoming bigger and with a lot of data and also sensitive data.
With server-side sessions, you can obtain a predictable cookie size and a lot smaller… I need between 20 and 40 bytes without sensitive data.
Remote logout
You know the so-famous “Close all excepted the current one” that kills any sessions on another app/browser.
You can’t do that with client-side sessions.
Key rotation
When you want to harden correctly, you’ve key rotation excepted when you refuse that any of your clients can be logged out due to it. In that case, you accept that you can be broken: RSA key + Quantum Computing = Headshot!
Server-side when you’re using the correct way, you’ve no key rotation because your CSPRNG/CPRNG does the job with reseeding and more.
Never use client-side sessions if you respect your users! – sycured