HTTP is by nature a stateless protocol, in which browsers make requests without first needing to establish a "session". But when someone visits a website to buy something, he expects the site to show the items in his shopping cart only to him, not to other users. The vast majority of sites establish a session using HTTP cookies, which are short strings that a website stores on the user's computer. Though the vast majority of users accept cookies for this reason, a minority of users reject cookies out of fear that a site will collude with other sites to build a dossier on the user for use in practices believed to intrude on a user's privacy. These include interest-based advertising and price discrimination.
There exist a few alternatives to cookies as a means of identifying a session, but each has substantial disadvantages.
A session ID can be stored in the URL, commonly in the query string.
In PHP, this technique is called session.use_trans_sid.
This method has the major drawback that URL-based sessions offer no separation between the identity of a session and the identity of a resource accessed during that session.
For example, it's common to share a link to a resource by copying the URL out of the location bar and pasting it somewhere.
Disclosing the session ID in this manner allows anyone else to hijack the session.
It's also common for a user to attempt to return to the front page of a site by deleting the entire path and query parts of the URL.
This causes inadvertent early logouts when, for example, a user chops off most of https://example.com/products/foo?sessionid=12345 and returns to https://example.com/ which loses the session identifier.
RFC 7617 defines the "Basic" authentication scheme, which sends a name and password with each request. This is fine for any site delivered through HTTPS.
However, Basic authentication offers no way to log a user out of a site. A user might want to end a session as a means against cross-site request forgery (CSRF). Or on a site without robust separation of authentication from authorization, a user might want to log out and log in as a different user in order to access resources exclusive to that user. Existing web browsers implement log out by making Basic authentication session-scoped, logging the user out of all sites at once when the last browser window has been closed. But in the era of tabbed browsing, having to close all other pages on unrelated origins is an unacceptable inconvenience.
There exist script workarounds using the XMLHttpRequest object that exploit browsers' behavior for storing incorrect credentials.[1]
But someone unwilling to accept cookies for privacy reasons is also unlikely to accept script for the same reasons.
TLS allows a browser to identify itself through a certificate. When the server requests client authentication, the user chooses a certificate to identify himself from among the certificates stored on the user's system. This login method is used by the Kount fraud-tracking system and the StartSSL certificate authority.
But TLS client authentication is a usability nightmare for non-technical users. Web browsers and operating systems have historically made it inconvenient for a user to switch from one certificate to another or to no certificate at all (for an anonymous view). Nor is it easy for a user to back up his client certificates in order to move them to a different device. Finally, client certificates historically aren't separated by origin. This either leads to the same tracking problem as cookies, if the user uses the same certificate across multiple sites, or presents the user with a bewilderingly long list of certificates, one for each site.[2]
Web browser developers can improve the usability of client certificates: