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

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.

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.

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:[email protected]". 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.

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

> What other way is there for managing se?

In the 90's and early 00's I used to see the session token in the URL of every request.

For example, instead of:

        <a href="https://news.ycombinator.com/threads?id=throwawayjava">Comments</a>

you write:

        <a href="https://news.ycombinator.com/<token>/threads?id=throwawayjava">Comments</a>

or more commonly:

        <a href="https://news.ycombinator.com/threads?id=throwawayjava&token=<token>">Comments</a>

And when making a JSON request, instead of:

        post_with_session_cookie("/auth/api/<et cetera>", ...)

you write:

        $.post("/auth/<token>/api/<et cetera>", ...)

This has other major problems; the most obvious is that it's extremely easy to accidentally session hijack ("oh here's the link to the completed order form: www.yoursite.com/orderForm?token=<my token>"). Also, the attack surface for session-hijacking XSS is a lot larger. There are other security problems.

You can mitigate some of these problems by changing the token on every request, but now your security problem is only a (massive) usability problem.

None of this is the default for any major web framework, which is probably why this style of authentication completely disappeared in the mid 2000's when people stopped rolling their own backends from stratch.

Sure. I guess I didn't do a very good job articulating my question. What I really meant to ask is what other alternative exist on the "modern web" to manage session state without cookies. Cheers.

Adding to the other replies, there's also IndexedDB, which can store considerably larger amounts of information cross-session.

Is there a difference between using the LocalStorage API and IndexDB? Are these similar? The same?

The LocalStorage API is a more efficient way to store data client side with a a cleaner API

But this is where cookies in modern browsers are stored - in the LocalStorage API no?

Aren't they complimentary instead of mutual exclusive?