[antsar]

One approach that doesn't rely on cookies is HTTP Basic Authentication.

The first request to a protected page will produce an authentication prompt[0]. Subsequent requests to the same site will automatically send the same set of credentials (in every browser I'm familiar with. This part of the spec seems to be optional [1]).

Using HTTP Basic Authentication, the server can track the user across different pages. All other state can be maintained on the server side, keyed to the user.

[0] https://i.stack.imgur.com/QnUZW.png

[1] https://tools.ietf.org/html/rfc7617#section-2.2

[bogomipz]

Sure the base64 encoded authorization credentials in the header are the unique identifier in this case. I guess I don't view this so much as an alternative to cookies for general internet browsing much as I do adding a thin layer of security for resources on things like corporate LANs.

[eli]

Why is this better than a session cookie? Basic auth is a pretty wonky user experience. Hard to customize the prompt and "logout" is awkward.

[antsar]

I didn't say it's better :) Just an alternative.

One way to handle logout (without closing the browser) is to have a logout link with a destination of "https://bad_username:[e-mail]". I believe this causes the browser to forget the original (valid) credentials and attempt authentication with the invalid credentials. This will fail, and produce a new login prompt. Then you have to close the prompt, and close the subsequent "401" page.

So yeah, it is awkward.

[eli]

Fair enough. I think modern browsers warn on links with username/password. The UX for basic auth is so bad it is not really a usable feature