Re: Auth scheme in 401 response header

[Reposting from another mail address hopefully subscribed to more lists]

On Wed, Jan 24, 2018 at 1:56 PM Jordan Chaitin <jordanchaitin@gmail.com>
wrote:

> Hi all,
>
> I’m a web developer looking for an appropriate http status code for
> situations when the user submits an invalid password.
>
> AFAIK, it is commonly understood that 401 is the most suitable


Hmm… If you're talking about your login form, then I would disagree. The
POST request means "validates those credentials and then create a
token/session-cookie", and the appropriate response is probably more a 400
than a 401.
401 is for the case when you try to access a protected resource and don't
provide credentials (in this case, you don't have a valid "session"), so
you'd be presented the login form instead: you're not authorized to use
this resource (granted, one could see the POST login form to be "create a
session", with the payload containing the credentials, so a 401 could be
seen as OK; I do disagree though, this is far-fetched IMO).
…


> but it requires that a WWW-Authenticate header is sent back. However, this
> header needs to mention the authentication type and the list of valid
> authentication schemes (as found at
> http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml )
> doesn’t include anything related to cookies. Google led me to a draft
> proposal by Thomas Broyer (
> https://tools.ietf.org/html/draft-broyer-http-cookie-auth) which seems to
> have quietly died almost a decade back.
>

Yes, in practice people use a 303 to the login page when the user tries to
load a protected resource.

I do use a 401 for AJAX requests though. I simply omit the WWW-Authenticate
then (which is non-compliant, but who cares?), or use a custom scheme.
Neither is "ideal", but nobody seems to care enough to try to standardize
anything (well, for AJAX APIs, you could use the Bearer scheme <
https://tools.ietf.org/html/rfc6750> provided you're also passing a
session-ID/token with an Authorization header with the Bearer scheme; the
fact that it's defined in terms of OAuth 2.0 does not make OAuth 2.0
mandatory, what matters is that you have a "bearer token", granting you
access only by being able to present it, with no other condition as to how
you obtained it)