Re: Auth scheme in 401 response header

On Wed, Jan 24, 2018 at 1:56 PM Jordan Chaitin <jordanchaitin@gmail.com <mailto: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 <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.

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