Cookies, Sessions and Tokens
Hello guys, sorry to disturb you all; I'm trying to make sense of those terms but they are not that clear. From what I have understand:
- Cookies: Use to store some data like user preference (like dark/light mode) - data persist even though browser is closed because data is stored on local machine; this has an expiry date.
- Session: Use to store data while the user is browsing; keep track of what user is doing such as logging in/shopping etc. (I'm still confused about that though, when we say keeping track of what user is doing, this seems vague)
- Tokens : Tokens are used for authentication; this enables a user to stay login for an amount of time.
Can someone just have a look whether the statements are correct and add more to that if needed please... I also have some question:
We say HTTP requests are stateless (meaning they don't remember anything); how do cookies/sessions/tokens handle that?
Also, I know we have a refresh and access tokens; why do we have 2 tokens? On certain websites, like facebook, if we log in and close the browser without signing out, it may happens we stay log in all the times unless the clear our history. Do tokens have a role to play here?
Last question, I also notice two terms, authentication and authorisation; what is the difference here please; authentication is when user log in for the first time; what about authorisation? (Sorry for the long question, really need to understand that)
58 Replies
I don’t think storing user preference is cookies, it’s local storage, in js I’m pretty sure handling cookies is a separate thing
it depends
you can store some settings in the cookies, but i highly advise against it
cookies are sent with each request, and have a limit of 4kb total
they are an extremely poor choice for settings
however, cookies are perfect for session tokens
and yes, http is a stateless protocol
a session, depending on the meaning, is treated by having something open the browser to the website and keep it open
http doesnt do anything with sessions: it's a communication protocol
that's like asking how the food tray handles you eating your lunch
fork would be more apt. The meal is the session, the fork is the transport protocol
the fork cares nothing for if there's a next bite, or if there was a previous one
i was taking "transport" literally, like as in the tray transports the meal
but your analogy makes more sense
hmm the fork represents our HTTP, HTTP cares if there is a next request... what do you mean by "if there was a previous one" like why would HTTP case in this case? Also, HTTP wouldn't remember the previous request unless we use some kind of cookies ?
http doesn't care about anything other than the current request
http is just the transport layer, and the cookies are not something that alters an HTTP request in any way. They're transported over HTTP, but won't alter the request
hmm what alters an HTTP request then please, like say for the dark theme or light theme, how does our website knows which preferences should be used
usually, dark or light themes are handled client side. The CSS contains both, and
prefers-color-scheme is used to figure out which to show
HTTP is literally just the postal service, taking requests from your browser and sending them to the server, then returning the response from the server to the browser.http? no, it doesnt
thats why it is stateless
thats complicated
it can be client-side, server-side or both or none
it can even be set by an admin
it's a huge "complicated"
generally, what can be done is to detect the user preference and then store it server-side and/or client-side
yep I see
just to clarify, from what I have understand for cookies and sessions (can anyone please confirm):
- Sessions: Each time we interact with a website, the server assign a session to us; this session is just a temporary container which stores information as long as the session is active (that is user doesn't log out or user doesn't close browser).
- Session ID: Each session for a particular website assign the user with a session ID; this session ID is just a way to uniquely identify a particular user on a website. Because a website is something that can be accessed by multiple users and so we need some ways to keep track which user has taken which actions.
- Cookies: This session ID is stored in what are known as cookies. Now we have a set-cookies header and a cookies header; the set-cookies header is what the server sends to the browser (basically the session ID). Now, each time a user interact with a particular web page from the website, the Cookies header sends back the session ID to the server communicating that this particular person has done this particular action
that depends on what you mean by "session"
an user having the browser open on a static website without a backend is also a "session"
hmm like having a session to make the website "stateful" rather than stateless
no, it's a browsing session
sessions are a vague concept, honestly. PHP has sessions that are tightly defined, but can last past browser sessions. Those work like you describe, PHP creates a session and gives you a session ID to store in a cookie.
But sessions are also used for other situations, usually a browser session that ends when you close the browser. Cookies can have an expiry when the browser closes which is called end of session, as well as session storage that wipes when the browser closes.
so a PHP session is a different concept from a browser session
and a PHP session only happens when the backend programmer actively creates one in code and utilizes it, it's not automatic
sessions can also be set to only last for the browser session, and expire imediatelly
and other backend languages or frameworks might have slightly different concepts of sessions
or different names for it too
yup
basically a big fat It Depends™️
yep, so there isn't any general way of defining it ?
not without being more specific in what you're defining
yeah I see, basically, I was referring to a session created by the server like when a user log in for example, a session is created to keep track of the user
that's not necessary for a user to log in, but that is one possible mechanic, yes
yepp I see, thanks !
I have a clearer idea now; I will just stick from what I've learned for now, digging more into that will be painful 😅 .... I will keep that for later....thanks for the explanation 💯
By the way, what is the difference between authentication and authorisation
another way to do it is to store an oauth2 token on client-side, send it over cookie, and the server always reads the user data from the database
that's not a session, but quacks and walks like one
and functions like one too
basically, authentication authenticates the user and authorization authorizes the user to do something
yep, now coming to tokens, basically they have replaced what sessions id were doing ? Like keeping track which user is currently log in something like that ?
not really
a session id is a token
in a way
Authentication is "you are who you say you are"
Authorization is "and this is what you're allowed to do"
basically, you have an access card to a building, and that card only lets you open specific doors
the authentication is the card letting you get into the building, and the authorization is which doors you are allowed to open
hmm I understand the concept of authentication and authorization but tokens are still vague... I know we have a refresh token and an access token; each time we log in for e.g, we are assign an access token; this access token has an expiry date; in order to keep surfing on the website, we need to refresh the access token else we will be signed out; this is done using a refresh token which can only be used once; this provide more flexibility in terms of security since if a refresh token is used twice, we know there is something not correct. So apart from the security thing, is there any difference from what were used earlier like session IDs, cookies etc ?
a token is the card
Tokens are also a concept who's implementation varies, just like sessions
hmm like the JSON Web Token thing
JWT
what is it used for
yes
a token is just a piece of secret that can be single-use or for permanent storage, that can be used for anything
you can have a token that tells the server you have temporary access to a restricted area of the building
yeah I see, a token is like a vip card ?
more like the vip membership
and the card can be a token too
yep I see, last question promise, can we have several tokens for a single website ?
you can have up to 4kb in cookies
what you do with the cookies is up to you
yep I see, ty !
you're welcome
I’ve been rolling around in this space trying to understand tokens and cookies and oauth2 myself lately.
I’m curious how the recent changes browsers have made to third party cookies affect developers. I’m curious how it used to operate and how the changes affected that , how devs had to alter their approach
sites that share login information between multiple domains may need to find a better way to do that work
an example of a website is stackoverflow
oh didn't know this was possible, like if I'm login on website Y, it may happen that my logins detail is shared to website Z ?
not usually your actual login details, just the session. And it also requires setup on the serverside for the site who's session is being shared, and on the serverside for the site that's using the other session. And it's heavily restricted in modern browsers, that's why there's often a lot of redirects.
yeah, it's pretty messy, but a miracle that it works
yep I see, for the example of stackoverflow, it uses shared login details ?
what do you mean with "shared login details"?
hmmm like what you mean by "sites that share information between multiple domains like stackoverflow"
none of the websites share your username and password
it's just a single login token that's set for all websites
ahhh ok I see
by the way that other domains uses same login token as stackoverflow? I didn't it stackoverflow shares it along other domains
it would make sense to use the same
ahhhh
I see
that's why we can use google to sign up for example
this is not related to stackoverflow only, for e.g same with gitHub
not exactly
Just read on that, they use something called OAuth
ah😅
yes, oauth2
those are oauth2 providers
and they give you a token that you can use to get information about the user
yeah I see, the thing is on multiple websites, we can register using our gmail account for e.g, basically for security purposes, our login details remain confidential, what enables us to create an account using our gmail account here? There must be some kind of token ?
- the site requests an oauth2 token from google
- google asks you to give permissions to the site
- you give permission to google
- google gives back the oauth2 token to the site
- the site requests your information (name, email)
- the site does what it needs
yeahh I see
it's clearer now , thanks !!
you're welcome