Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list

[Nico Williams <[e-mail]>]

On Fri, Jan 27, 2023 at 08:43:51PM -0500, Simo Sorce wrote:
> *However* the main issue that plagues HTTP(s) when it comes to
> authentication is the requirement to re-authenticate each request
> because clients tend to create a new connection every time they want to
> make a new request.

The answer to this is always cookies.  And with H2 the cookie only
really has to go over the wire once (in each direction).

> I would like to see a standardized mechanism to return a bearer token
> (aka session cookie) that allows the client to retain (if they want) an
> authorization token to be used in following requests.
> 
> The last thing we need is for people to invent their own caching
> mechanisms to prevent browsers or other client from constantly
> prompting for credentials on naive configurations.

There must be generic cookie construction schemes out there.  It'd be
nice to have a standard, but obviously much cookie contents beyond
obvious things like expiration times is going to all be application-
specific.

This is all mostly a solved problem in frameworks and libraries.  It's
not a pressing problem.  I wouldn't hold up any other auth work over it.

> The mechanism to deal with "sessions" should be built-in, not an
> exercise left to the reader.

"But HTTP is stateless!"  HTTP does have state and sessions: via
cookies.  And H2 adds header compression which essentially makes HTTP
much more "aware of connections" than H1, but the semantics don't
change, and it's still all about keeping state via cookies.  There's no
changing this.

Nico
--