Re: Introducing a Session header...

2012 is not 1992, quite a lot has changed since

* Server state is now cheap, but it remains difficult to scale.

If you have an service that will fit on one server then server side
state is cheap and plentiful. I just built a new machine with 16GB on
2 DIMMS for $98. If I was building a server I would automatically fill
it with 64GB just because I can.

Server side state is no problem at all until you have a service that
requires 64.00000001 Gb and then you are into a big problem. You can
go up to 256Gb with 32 threads for about $10K. But you have to use
registered memory which isn't even stocked at my favorite supplier.


So the ability to use a router to front end the system and offload
requests in a sensible fashion is a very big win here, it makes
deployment of applications that are inherently statefull very much
more practical. The lack of support in legacy browsers is not a major
concern to me as I can simply consider all requests without the token
to be one bucket of work and resign myself to having to one-off that
particular site.


* People use multiple browsers, state tends to be bound to account profiles.

Not so long ago it was fairly unusual for someone to have more than
one machine in daily use. Today it is absolutely routine. So  that
makes client selected state identifiers rather less useful than server
side so that the server has control over where the requests are being
directed. This is the reason that we want a session identifier rather
than relying on the source IP address.


* What is often required is a session authenticator rather than just
an account identifier.

It is a protocol design error to rely on confidentiality as a means of
protecting authentication data sent over the wire. A password exchange
scheme should establish knowledge of the password without disclosing
the password. In general an authentication scheme should demonstrate
knowledge of the authentication secret (preferably a cryptographic
key) without revealing it.

There are in fact two separate authentication concerns in HTTP:

1) How does the service determine that Alice is making the request on
behalf of 'alice' at the start of a session?

2) How does the service re-authenticate subsequent requests in the
same session (which may span multiple TCP/HTTP sessions).


If the session ID is being used as a proxy for authentication, I would
prefer to do the job right.

Received on Friday, 20 July 2012 19:36:49 UTC