Re: Auth scheme in 401 response header

Thank you so much for helping understand this better!


On Jan 29, 2018, at 11:58, Mark Nottingham <mnot@mnot.net> wrote:

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?

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. 

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

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/or the body.

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. 

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

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

Cheers


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

Received on Tuesday, 30 January 2018 17:37:54 UTC