Subject: Auth scheme in 401 response header

From: Jordan Chaitin <[email-masked]>
Date: Wed, 24 Jan 2018 12:56:52 +0000

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 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. 

I would be grateful if someone could throw some light on current guidance what authentication scheme to use in the www-auth-header with the 401 response when the user submits a wrong password.

Look forward to hearing from you..

Cheers!

---

From: Jordan Chaitin <[email-masked]>
Date: Wed, 24 Jan 2018 17:10:04 +0000

Many thanks for the clarifications and correction. 

Omitting out the WWW-Authenticate header seems the most straightforward for 401s but including that header and simply sending a non-standard scheme (i.e. “cookie”) sounds like a better idea - seeing as we’d be going against the standard anyway, so might as well make it as meaningful as possible. 

Thanks again, 
Cheers

> On Jan 24, 2018, at 20:50, Thomas Broyer <[email-masked]> wrote:
> 
> [Reposting from another mail address hopefully subscribed to more lists]
> 
> On Wed, Jan 24, 2018 at 1:56 PM Jordan Chaitin <[email-masked]> wrote:
> Hi all,
> 
> 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)

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 24 Jan 2018 15:21:02 +0000

On Wed, Jan 24, 2018 at 1:56 PM Jordan Chaitin <[email-masked] <mailto:[email-masked]>> wrote:
Hi all,

 
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 <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 <https://tools.ietf.org/html/draft-broyer-http-cookie-auth>) which seems to have quietly died almost a decade back.

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 <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)

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 24 Jan 2018 14:52:28 +0000

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jan 2018 17:28:49 +1100

> On 24 Jan 2018, at 11:56 pm, Jordan Chaitin <[email-masked]> wrote:
> 
> Hi all,

Hi.

> I’m a web developer looking for an appropriate http status code for situations when the user submits an invalid password. 

Are you using the HTTP authentication framework (RFC7235), or something else? I.e., how is the password submitted?

> AFAIK, it is commonly understood that 401 is the most suitable but it requires that a WWW-Authenticate header is sent back. However, this header needs to mention the authentication type and the lis…

Aha.

401 is for use with the HTTP authentication framework, not cookies (unless someone specifies a cookie-based authentication scheme to make it explicit; that's been discussed in the past, but never got traction).

Using it for other things (like cookie-based auth) is going to confuse generic software (e.g., proxies, CDNs, browsers, etc.).

200 is fine here; it indicates that the request was processed successfully as far as HTTP is concerned; the application using HTTP still can have problems, but they can be conveyed in headers and/or the body.

FWIW, this may also help:
  https://www.mnot.net/blog/2017/05/11/status_codes

> I would be grateful if someone could throw some light on current guidance what authentication scheme to use in the www-auth-header with the 401 response when the user submits a wrong password.

Hope this helps.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Jordan Chaitin <[email-masked]>
Date: Mon, 29 Jan 2018 14:57:42 +0000

Thank you so much for helping understand this better!

On Jan 29, 2018, at 11:58, Mark Nottingham <[email-masked]> wrote:

Hi.

> Are you using the HTTP authentication framework (RFC7235), or something else? I.e., how is the password submitted?

The password is submitted in the body of a Post request via an AJAX call (instead of form submit using Post method). When there’s a match, the server sets a (session) cookie in the 200 OK response. 

> 401 is for use with the HTTP authentication framework, not cookies (unless someone specifies a cookie-based authentication scheme to make it explicit; that's been discussed in the past, but never g…

I was just wondering if one of the many 4xx status codes could be used to convey if the password didn’t match - considering that HTTP is after all an Application Layer protocol (in both the OSI and IP Suite models) which has to do with end user processes. That this particular bit of information, i.e. the password, had to be input by a human(?)(or script with config files) should not matter - if one considers that the goal of the request was to authenticate the user-application to gain access to a certain remote resource. 

> Using it for other things (like cookie-based auth) is going to confuse generic software (e.g., proxies, CDNs, browsers, etc.).

Specifying a cookie-based auth scheme with 401 seemed the most pragmatic, but not in light of this ^^

> 200 is fine here; it indicates that the request was processed successfully as far as HTTP is concerned; the application using HTTP still can have problems, but they can be conveyed in headers and/o…

Yes, that makes sense - HTTP, being a protocol, has nothing to do with whether the password was correct: separation of concerns and all that. It should be handled by/within the particular application. 

>> I would be grateful if someone could throw some light on current guidance what authentication scheme to use in the www-auth-header with the 401 response when the user submits a wrong password.

Yes, very much so. Thank you! :-) 

Cheers