This is a personal note explaining how a website uses cookies and sessions to keep users connected to the site.
These are rough conceptual notes, not exact specifications.
Problems with HTTP communication
- HTTP communication is a one-time, one-off communication, so it is not possible to keep the connection alive
- HTTP communication has no user identification mechanism, so it is impossible to determine which user is connecting
- So, it is necessary to implement some mechanism to keep users connected in a series of HTTP communications.
Solution
After user authentication is complete, the server issues a user identifier, sends the identifier in the response to the browser, and sends the identifier to the server each time the browser accesses the server from the next time onward, so that the server knows which user is accessing the server.
And one method of exchanging identifiers is to use cookies.
What is a cookie?
Bullet points for rough specifications, etc.
- A cookie is a data pair of a variable name and its value
- Cookies are set on the server side and sent to the browser as a response
- Cookies received are stored in the browser
- Sends a stored cookie to the server when the browser accesses the site again
- Browser can also add variables to cookies or change the value of existing variables
- Cookies can be set to expire.
- The effective range of cookies can be narrowed down by domain or path.
- If the cookie validity range is narrowed down by domain or path, the cookie cannot be seen by servers in other domains or paths.
Simplest implementation (NG for security)
- When a user completes login, the server creates and returns a cookie with the variable "user ID" and the value "user ID value".
- From then on, when the browser accesses the server, the cookie is sent to the server.
- The server side obtains the "user ID" value from the received cookie to identify the user and maintain the connection.
The simplest implementation issues
- The specification allows the browser to see and change the cookie, so it can be spoofed.
The simplest solution to the simplest implementation problem
- Server side sends encrypted user identifier, not user ID, to browser as a cookie
- This encrypted user identifier is commonly referred to as a "session ID".
- When a browser accesses the server, the server obtains a "session ID" from the cookie it receives and then recovers a "user ID" to identify the user and maintain the connection.
- User identifiers are encrypted, making it difficult to generate and impersonate another user's user identifier
About the Session
- The method of generating session IDs is not defined in the HTTP specification. It depends on the server-side implementation.
- Each programming language has a major session library and often uses them for session ID generation
- The default implementation of many of those libraries generates a unique, hard-to-guess value as the session ID, ties user data such as "user ID" to it as a key, and stores it as key-value data in a local file or in memory
- Then, when accessed from a browser, the session ID is read from the cookie, and the session ID is used as a key to recover the corresponding user data from the key value data.
- Key value data is stored in local files and memory on the server, so if multiple servers are installed to distribute the load, the destination server will change for each connection, making it impossible to maintain sessions.
- So, we often try to store key-value data in a database rather than locally, so that the appropriate user data can be restored no matter which server is accessed
Impressions, etc.
It was necessary to create a site that authenticates users.
It is better to leave such a security-related part to a library instead of implementing it yourself, but even if you use a library, it is better to know the concept.
Even in the case of single-page applications, the basic idea is the same: the session ID and cookie are simply replaced by a token and Auth header, and the information is retrieved and verified from the encrypted ID.
