Staying signed in

Ava signs in to the photo application and opens an album. Then she opens another album, changes its title, and visits her account settings. The application does not ask for her password on every page. Somehow, it connects these separate requests to the sign-in it accepted a moment ago.

That continuity is a session. HTTP does not remember Ava by itself. The application needs a way to recognize a later request, find the account it belongs to, and decide whether to keep accepting it.

In one common design, the server creates a session record after sign-in. It records the account and the session's lifetime, then gives the browser a randomly generated, unpredictable identifier. The identifier points to the record; it does not need to contain Ava's password or profile.

The identifier travels in a cookie: a small named value that a server asks the browser to keep, using a Set-Cookie header in a response. On later requests to the same place, the browser sends the cookie back by itself in a Cookie header. The server looks up the session and finds Ava's account. That explains how opening a second album can work without another password prompt.

The cookie is now valuable evidence of an accepted sign-in: a request that carries it is treated as Ava's. So two questions matter. Where will the browser send it, and who else could get hold of it?

A cookie's scope, meaning here the set of addresses it applies to, decides where it goes. By default the browser sends it back only to the host that set it. A server can widen that with a Domain attribute, so that photos.example and every name under it, such as accounts.photos.example, receive it. Every name inside the scope receives the session, even a forgotten name that now serves someone else's pages, so a session cookie is usually kept to the one host that needs it. The Secure attribute adds another limit: the browser sends the cookie only over HTTPS, never over a connection anyone on the network could read.

Pages also run scripts, small programs written in JavaScript that a site sends with its pages so they can respond as you use them. If an attacker gets their own script into one of the site's pages, for example through a comment the site displays without treating it as plain text, that script runs with the page's access. This is cross-site scripting. The HttpOnly attribute stops scripts from reading the cookie, so an injected script can't copy the session to use somewhere else. It can still act within the page while it runs, so keeping scripts out matters too.

The last concern is other sites. A page on another site can make Ava's browser send a request to the photo service, for example with a hidden form that submits itself with POST. If the browser attached her session cookie, the request would arrive looking like something she chose to do. This is cross-site request forgery. Browsers decide what counts as another site using the registrable domain from Clients, servers, and addresses. The SameSite=Lax attribute tells the browser to leave the cookie off requests that other sites start, such as forms that submit with POST and the images they load, while still sending it when Ava follows an ordinary link to the photo service.

These attributes limit where the cookie can travel and what can read it. They work alongside the server's own session checks rather than replacing them.

Recognizing Ava's session is only the beginning of a request. The server must also check that the session remains valid and that Ava can perform the action she requested. Signing in once does not give her access to every album.

There is another problem at the moment of sign-in. Many applications start a session before anyone signs in, to remember a language choice or what is in a basket. Suppose an attacker starts one of these anonymous sessions, notes its identifier, and gets Ava's browser to use it. A page on a name under photos.example that the attacker controls could do that by setting a cookie for the whole domain. If the server keeps that identifier when Ava signs in, the attacker may be able to use the same value to act as Ava. This is session fixation.

To prevent that handover, the application issues a new, unpredictable identifier when authentication succeeds and stops accepting the old one. Replacing the cookie in Ava's browser is only half the job; the server must reject the previous value too.

For a sensitive change, such as replacing a password, the application may ask Ava to authenticate again. That produces fresh evidence of control. Merely changing a session identifier does not.

Later, Ava walks away from her computer. An idle timeout can end her session after a period without activity. An absolute timeout limits the total session lifetime even if she keeps using it. A service chooses these limits according to what it protects and may renew sessions under its own rules.

When Ava chooses Sign out, the server-stored design we followed needs to invalidate the session record and remove the browser's cookie. Otherwise, a copied cookie could still point to a session the server accepts.

Closing a browser is less definite. A browser may restore its cookies when it reopens, and an old page may remain visible after a session ends. The useful question is whether the server accepts the next protected request.

So far, one application has managed this continuity on its own. Once sign-in happens at a separate service, that service keeps a session too, and the two sessions can end at different times.