DEV Community

loading...

Discussion on: What is really the difference between Cookie, Session and Tokens that nobody is talking about ?.

Collapse
andreidascalu profile image
Andrei Dascalu

"So the server will store the session information in the database " - what database? Session (even when they exist at all) depend on server side implementations. I haven't heard of one that uses a database by default. Most go to temporary files or in-memory. None that I work with are even able to use a database without third party libraries, at most there's a native option for a k/v store. I would stay away from anything that stores session data to dB.

Collapse
ssimontis profile image
Scott Simontis

ASP.NET's legacy Forms Authentication used to allow using a SQL Server database for session storage, but I believe ASP.NET Core favors in-memory engines, although you are technically free to implement whatever you want if you implement the proper interfaces. For example, using Redis or memcached as a session store provider would alleviate the need for sticky sessions on a load balancer.

Collapse
dev_emmy profile image
nshimiye_emmy Author

Yeah, I think that's the reason as to why cookie-based authentication is not that much used nowadays. Most applications use token based authentication

Collapse
andreidascalu profile image
Andrei Dascalu

Not sure that's the real alternative. Sessions need to be stored somewhere server side (while tokens don't) but token are also stored in cookies (just not sent via cookies)
Client side it's the same type of problem. You need to store the session Id or the token somewhere on the client before it's sent back to server, preferably in a way that's protected against xss and csrf.

Thread Thread
dev_emmy profile image
Thread Thread
codingsafari profile image
Nico Braun

When using tokens, you still need to maintain a "deny-list" on the backend, with tokens that have been revoked. The overhead is significatly lower than maintaining all the sessions though.

Thread Thread
dev_emmy profile image
Thread Thread
andreidascalu profile image
Andrei Dascalu

Not necessarily, since tokens expires. You can, if you want to, but you don't have to. Tokens should have short lifespans like a few minutes and extend their lives through refresh. You don't need to revoke a token for a few minutes, just flag the account to temporarily deny renewal.

Thread Thread
codingsafari profile image
Nico Braun • Edited

usually its more than a few minutes and usually yes you certianly revoke the token as soon as the user clicks logout. You are not going to let the token be valid. And thats just the scenario where probably nothing bad will happen. Sometimes you may know that a token is comprimised and you need to revoke. Even few minutes then can cause damage.

Thread Thread
andreidascalu profile image
Andrei Dascalu

well, like I said, it's up to how you design your application and what concerns you have there. Suffice to say it can be nice to have, but it's not a universal requirement, not by a longshot.

Thread Thread
dev_emmy profile image
nshimiye_emmy Author

yeah, it all depends on how you want to design your application

Collapse
jaguart profile image
Jeff

I've used MySQL to store user sessions in a small scale system - about 300 simultaneous users. The reason being that with reasonable cache and the use of MyISAM tables, you have lightning fast structured storage of large collections of session data for each user, stored in memory but accessible using a structured query language. I usually store the session details in multi-record format, never as blobs.
It makes it easier to construct tools for your system admins to see exactly what each user is doing in real-time, and even for your admins to assume and safely change the session of a logged in user for accurate real-time support.

Collapse
rendlerdenis profile image
Denis Rendler

Actually lots of languages and specially frameworks offer support for storing the session data in databases. Now there might be a bit of a difference in the way we define a database, but from my perspective even Redis is a db since it allows storing the data long term on disk. I guess the session being stored in dbs is more common in SOA world where you could have several instances of a service being deployed. So, in this case you can either share the session or tag the user to always direct him to the correct instance.

Collapse
jcubic profile image
Jakub T. Jankiewicz • Edited

If you want sessions that are written without cookies you need your own solution for sessions, You can use a database for that. I think that most session solutions use cookies by default.

Collapse
andreidascalu profile image
Andrei Dascalu

Not sure you can have sessions without cookies. Session data is not stored in cookies. Only session identification is passed by cookies. Server side defaults to tmp file stored and configurable to k/v stores.

Thread Thread
jcubic profile image
Jakub T. Jankiewicz • Edited

Yes, you can. You can keep the token in memory or LocalStorage and send it with every request. I'm using something like this with JSON-RPC where the token is the first argument to remote procedure. But as I've said you will need to have your own session mechanism because most default sessions use cookies. And for that you can use the database, of course, you can also use files or both (SQLite that is both file and database).

Thread Thread
andreidascalu profile image
Andrei Dascalu

No, you're talking about a totally different things. Sessions are a concept proper to web servers, where some information related to user activity can be stored server side (in files or k/v stores) and are identified by a web server generated ID. That ID, by default navigates in cookies OR GET parameter (by default SESSION_ID=xxx). That's how sessions work. Some people try to use tokens as session storage in itself, but that in itself is a custom implementation. Using tokens to store session data is wrong. You can use tokens to store session id's, but that's fairly pointless. Tokens are used to store authentication (and authorization, stometimes) to authenticate requests (not to store session data). The issue I was talking about is server side data storage, the kind of that that you can't & shouldn't store client side.
Also, in memory storage is really bad, it's vulnerable to lots of attacks. LocalStorage is also bad (mostly it's also limited so you can't really store the kind of information sessions need) and vulnerable mostly to XSS. Secure cookies are best for storing tokens (though not as a means of communication, you write to cookie, then read to send separately while the server expects the token in dedicated headers and ignores the cookie data).

Thread Thread
jcubic profile image
Jakub T. Jankiewicz

I think you don't u understand what I just wrote and keep changing the subject. First, you said that you can't use the database which is not true because you can use it for the session if you create your own mechanism.

Then you're contradicting yourself because first, you said that you can't have a session without cookies, and then next you said that you can use the GET parameter for the session_ID.

My comment only meant that you can create the session with a database and without cookies. You don't need to rely on whatever the platform gives you.

Thread Thread
andreidascalu profile image
Andrei Dascalu

No man, what I'm talking about is the context of the OP: cookies vs sessions vs tokens, used as means of exchanging information that stores information about user activity. These terms were used under their proper definition (including session, as a server-provided ephemeral storage).
Yeah, sure, you can create your custom system, you can create your custom anything but what I was talking is what you can use to integrate within the sever provided framework (which already manages how clients are identified and whatnot). That's way beyond the topic of using what's provided. My point was merely to correct a statement in the OP which implied that databases are somehow part of the session mechanism (they're not). The session mechanism as per OP is what the server provides you. You could create your own, but that's not the same thing.
Also, the mere fact that something exists doesn't mean it's usable (session id in URL is as exposed as you can get) so I wouldn't consider as something that's in your toolbox.

Thread Thread
kevinmduffey profile image
Kevin Duffey

Andrei is correct.. Jakub seems to miss Andrei's point.

Forem Open with the Forem app