Because HTTP is stateless, in order to associate a request to any other request, you need a way to store user data between HTTP requests.
Cookies or URL parameters ( for ex. like http://example.com/myPage?asd=lol&boo=no ) are both suitable ways to transport data between 2 or more request.
However they are not good in case you don’t want that data to be readable/editable on client side.
The solution is to store that data server side, give it an “id”, and let the client only know (and pass back at every http request) that id. There you go, sessions implemented. Or you can use the client as a convenient remote storage, but you would encrypt the data and keep the secret server-side.
Of course there are other aspects to consider, like you don’t want people to hijack other’s sessions, you want sessions to not last forever but to expire, and so on.
In your specific example, the user id (could be username or another unique ID in your user database) is stored in the session data, server-side, after successful identification. Then for every HTTP request you get from the client, the session id (given by the client) will point you to the correct session data (stored by the server) that contains the authenticated user id – that way your code will know what user it is talking to.
Explanation via Pictures:
Simple Explanation by analogy
Imagine you are in a bank, trying to get some money out of your account. But it’s dark; the bank is pitch black: there’s no light and you can’t see your hand in front of your face. You are surrounded by another 20 people. They all look the same. And everybody has the same voice. And everyone is a potential bad guy. In other words, HTTP is stateless.
This bank is a funny type of bank – for the sake of argument here’s how things work:
you wait in line (or on-line) and you talk to the teller: you make a request to withdraw money, and then
you have to wait briefly on the sofa, and 20 minutes later
you have to go and actually collect your money from the teller.
But how will the teller tell you apart from everyone else?
The teller can’t see or readily recognise you, remember, because the lights are all out. What if your teller gives your $10,000 withdrawal to someone else – the wrong person?! It’s absolutely vital that the teller can recognise you as the one who made the withdrawal, so that you can get the money (or resource) that you asked for.
Solution:
When you first appear to the teller, he or she tells you something in secret:
“When ever you are talking to me,” says the teller, “you should first identify yourself as GNASHEU329 – that way I know it’s you”.
Nobody else knows the secret passcode.
Example of How I Withdrew Cash:
So I decide to go to and chill out for 20 minutes and then later I go to the teller and say “I’d like to collect my withdrawal”
The teller asks me: “who are you??!”
“It’s me, Mr. George Banks!”
“Prove it!”
And then I tell them my passcode: GNASHEU329
“Certainly Mr. Banks!”
That basically is how a session works. It allows one to be uniquely identified in a sea of millions of people. You need to identify yourself every time you deal with the teller.
If you got any questions or are unclear – please post comment and I will try to clear it up for you. The following is not strictly speaking, completely accurate in its terminology, but I hope it’s helpful to you in understanding concepts.