Re: Auth scheme in 401 response header

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 <t.broyer@gmail.com> wrote:
> 
> [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)

Received on Monday, 29 January 2018 06:13:01 UTC