To understand the difference between cookies, sessions and tokens we need to get back on the basics. Let's say you want to login to your bank accou...
For further actions, you may consider blocking this person and/or reporting abuse
"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.
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.
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.
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.
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.
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.
Hello nshimiye_emmy,
thank you for your article.
It helped me understand Token a bit better.
This part helped me the most:
"[...]if you click yes the app will receive a token granting access to your transactions but the app will only view transactions, it will not be able to wire transfers or to see other details which you would normally be able to see when you login in your bank account. "
Still, I understand that in a bad situation the app will tell you, it will only read transactions, but the truth is, it could request a token that offers more than just reading options without you knowing, right? Wouldn't it be wiser to tell the bank what token the app can use? I apologize in advance if I get anything wrong here :)!
The bank is the one responsible for giving the token to another app, so it really knows what king of access granting it should give to a third-party website or app.
I'd like to add to.. or perhaps amend Nico's statement a bit about Tokens... while technically correct.. tokens keep the state (as much as the server implementation puts in it).. the client should ideally NOT have access to decode/use the token itself. The server should only send the token on specific path (like /login /token, /refresh, etc) and should be httpOnly and secure.. so that the JS code in a client can not access or decode the token. You might ask.. then how the heck is the client app supposed to get at the details to say.. display the name, email, etc? Well.. when the request to login is made.. which returns the generated token at that point.. it would also return a response body with JSON (for example) that contains the bits the client would use in say the UI. Some might say.. well this is insecure.. but think about it (if you are one of those that think this is the case).. accessing and decoding the token in the client is even less secure and the result is the same (and even more) data. So.. the way a server should use JWT tokens.. is to store things like useId (or the user of that session), and other pieces of data that allow the server side (upon receiving future requests WITH the token) to decode the token, pull the values out and use them in some manner than negates the need to do a DB lookup on every request. Say.. to do a DB query that needs the userId (which is likely a column in several tables in order to tie things to that user). This ultimately keeps the server side largely stateless.. and avoids the client side from accessing secure things like userId.. which should never be allowed to be accessed by consumer UNLESS the system is built that way.. which is as far as I have understood..bad design. If anything, make use of UUIDs as secondary IDs that can be changed/migrated/etc without affecting the actual DB structure.
Their are of course many ways this can be modified to do more or less the same thing.. but just wanted to put it out their that ideally the JWT token should NOT be decoded by the client.. and should NOT be stored in local storage. It should be httpOnly flag, secure flag and only as a cookie.. so for browsers and many nodejs/js libraries.. automatically sent on every request (or those that match the path the token is issued for).
I'm not sure if you're aware but SESSION_ID is a form of a TOKEN. Unless you talk specifically about JWT. See Wikipedia it even have session token redirect to Session_ID en.wikipedia.org/wiki/Token
Dapatkan informasi terbaru dan permainan yg hebat dari situs judi online terpopuler di Indonesia yang memberikan layanan bermain fairplay di pragmatic play.
Our Website : asphalt-berlin.com/
heretechs.com/
viagracongress.com/
asianbookie.id/
asianbookie.site/
daftarslotonline.id/
agenslotonline.site/
anjumanversova.org/
michaelkors-outletonline.cc/
cavweb-forums.co.uk/
purchasevyvanseonline.net/
tell-someone.org/
peda.net/p/qqslotonline/qqslot/jok...
peda.net/p/qqslotonline/nagabola
peda.net/p/qqslotonline/bola88
peda.net/p/qqslotonline/qqslot
"SESSION STORED IN A COOKIE" session is never stored in the cookie and there is more to tokens than JWT. The token can be an identifier that is saved in a cookie that matches the session on the server. So you can have all your cases as one case.
I did not say that "SESSION STORED IN A COOKIE" instead if you read well I said "Session data is stored on the server side, but a seession_id is stored on client side in a cookie. It allows the server to match a given user with the right session data""
Please read it again, this is the section title copy/paste from the article I didn't wrote this down:
SO YOU ARE PROBABLY WONDERING WHAT IS THE DIFFERENCE BETWEEN A TOKEN AND A SESSION STORED IN A COOKIE
ohhh sorry about that, updated. thx
Great article
thanks
Thanks for the artical, it was really helpful and wonderfully explained !!
thank you so much! I really appreciate that.
Very well explained.
thx, I appreciate
exactly!!
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.
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.
yeah, it all depends on how you want to design your application
Usefully~
thanks for clarity @dev_emmy