Actually, I split this to a separate topic, because it's a different question!
Generally, when dealing with sessions, you use a data store with timeout or time-to-live of some sort. Examples include memcached, Redis, or Cassandra.
For HTTP, when a user logs in, you create a new session and identify it with a session ID. Use a strong random number and verify that it's not already existing. Store information about the session in your data store, and store the session ID in a cookie in the browser.
When you receive HTTP requests with a session ID cookie, look up that ID in your data store; if it's still there, the session is valid.
The session ID needs to be hard to guess, and you need to have billions more session IDs than you have active sessions to defend against guessing attacks, but that's easy with a 128 or even 256 bit strong random number as your session ID, coupled with not allowing more than a dozen bad logins or bad sessions from the same source IP in some amount of time (say, 5 minutes.)
PHP specifically has some session management built in. By default, it just stores the data in a local file, so it only works on a single machine; you can extend it to use memcached or whatever once your service outgrows a single server. But it's also pretty reasonable to build your own as described above.