Re: [http-auth] Why is there no SASL support in HTTP?

Rick van Rein <> Thu, 05 January 2017 09:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B168B129439 for <>; Thu, 5 Jan 2017 01:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZfSNXovuP421 for <>; Thu, 5 Jan 2017 01:16:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FB17128E19 for <>; Thu, 5 Jan 2017 01:16:43 -0800 (PST)
Received: from airhead.local ([IPv6:2001:980:93a5:1:3da7:3bf8:9c50:2ca7]) by with ESMTP id UZGe1u0080KuCFd01ZGfTq; Thu, 05 Jan 2017 10:16:41 +0100
Message-ID: <>
Date: Thu, 05 Jan 2017 10:16:37 +0100
From: Rick van Rein <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [http-auth] Why is there no SASL support in HTTP?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jan 2017 09:16:46 -0000

Hi Tony,

Thanks a lot!

> 1) a mechanism for SASL mechanism discovery.
> 2) the willingness by client and server implementers to extend this into other SASL mechanisms.
> #1 could be solved in a straightforward fashion. But I don’t think there’s enough interest currently for #2.

I have a very concrete place where I want it, and it doesn't have the
usual chicken / egg problem:

The Nginx proxy has a "Auth Request" mechanism where authn / authz can
be performed via a HTTP call to a backend; status codes 401, 403 or 2xx
are interpreted and output header values may be harvested.  A similar
mechanism could be used for a SASL backend.

This could directly integrate with its backends for POP3, IMAP, SMTP and
(3rd party) XMPP.  Although there's no direct need to standardise it for
this internal purpose, it may be the best way to go.

That may turn out to be a useful bootstrapping path, making it flow into
closed systems and gradually spreading out.  Wishful thinking?  There's
no way to know but to try...

What you are stating is mostly pragmatic, and the need to build up
enthousiasm for writing it down.  I think HTTP SASL is well worth the
effort, and at least allow HTTP programmers to get away from the in-site
coding of password logic, and adopt more mechanisms.  So I now feel
encouraged to write it down.