Subject: Re: WWW-Authenticate, Authorization and 401's

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Aug 2007 18:31:00 +1000

Discussion on the list, as well as in Chicago, seems to be leaning  
towards firming up the combination of 401, WWW-Authenticate and  
Authorization as a framework, possibly described separately.

If that's the case, I'd take a stab and say that 401 is specific to  
authentication mechanisms that use that framework. I.e., it's not  
just a challenge for *any* authentication to be presented, but for  
authentication to be presented using the header defined for it. After  
all, 401 and WWW-Authenticate are already tightly bound (as you point  
out).

Does that seem reasonable?

Cheers,

On 26/07/2007, at 10:30 AM, Hugo Haas wrote:

>
> Hi,
>
> I'm trying to figure out how the WWW-Authenticate header relates to  
> the Authorization header.
>
> Authentication in an HTTP request is not always done with the  
> Authorization header. It's sometimes done with cookies for example.  
> When a user is not authenticated and authentication is required,  
> returning a 401 seems natural:
>
> [[
>
> 10.4.2 401 Unauthorized
>
>    The request requires user authentication.
>
> ]] -- RFC2616
>
> 401 requires a WWW-Authenticate header, which itself requires a  
> scheme and a realm:
>
> [[
>
>    The response MUST include a
>    WWW-Authenticate header field (section 14.47) containing a  
> challenge
>    applicable to the requested resource.
>
> ]] -- RFC2616
>
> and:
>
> [[
>
>    The 401 (Unauthorized) response message is used by an origin server
>    to challenge the authorization of a user agent. This response MUST
>    include a WWW-Authenticate header field containing at least one
>    challenge applicable to the requested resource.
>
> […]
>
>    The realm directive (case-insensitive) is required for all
>    authentication schemes that issue a challenge.
>
> ]] -- RFC2617
>
> The scheme and realm are concepts that are core to the HTTP  
> authentication framework defined in RFC 2617. However, it's not  
> clear whether the Authorization header is the required response to  
> this WWW-Authenticate challenge:
>
> [[
>
>    The client MAY repeat the
>    request with a suitable Authorization header field (section  
> 14.8). If
>    the request already included Authorization credentials, then the  
> 401
>    response indicates that authorization has been refused for those
>    credentials.
>
> ]] -- RFC 2616
>
> [[
>
>    A user agent that wishes to authenticate itself with an origin
>    server--usually, but not necessarily, after receiving a 401
>    (Unauthorized)--MAY do so by including an Authorization header  
> field
>    with the request.
>
> ]] -- RFC 2617
>
> Does this mean that the client may repeat the request with  
> credentials, and if so this must be done with the Authorization  
> header, or that the client may repeat the request with the right  
> credentials, and may do so with the Authorization header or using  
> some other way?
>
> If the former, that would mean that the 401 error code is reserved  
> to the use of the Authorization request header. That would be  
> unfortunate as having an error code for standard unauthorized  
> responses is handy for obvious reasons.
>
> Additionally, RFC 2616 talks about 401 pertaining to user  
> authentication:
>
> [[
>
> 10.4.2 401 Unauthorized
>
>    The request requires user authentication.
>
> ]] -- RFC2616
>
> while RFC 2617 talks about authenticating the user agent:
>
> [[
>
>    The 401 (Unauthorized) response message is used by an origin server
>    to challenge the authorization of a user agent.
>
> ]] -- RFC 2617
>
> A request may carry credentials for a number of things (the user,  
> the calling application, etc.), and 401 seems like a good response  
> code for those, with the meaning that some credentials that the  
> server was expecting were not found.
>
> Regards,
>
> Hugo

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2007 11:30:23 +0200

Mark Nottingham wrote:
> authentication mechanisms that use that framework. I.e., it's not just a 
> challenge for *any* authentication to be presented, but for 
> all, 401 and WWW-Authenticate are already tightly bound (as you point out).
> 

Not fully convinced.

If we say that 401 may only be used for authentication within the 
RFC2617 framework, then we either

- force servers to use that framework (unlikely to succeed with today's 
schemes), or

- force servers not to return a 401 at all.

I think the latter would be bad: in this case I'd prefer a 401 over a 
400 or (gasp!) a 200.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 17 Aug 2007 11:49:00 +0200

Am 17.08.2007 um 11:30 schrieb Julian Reschke:
> I think the latter would be bad: in this case I'd prefer a 401 over  
> a 400 or (gasp!) a 200.

Well, sending WWW-Authenticate along with 401 is a MUST. So, how  
would a server send a 401 *without*
  complying to the basic framework Mark is talking about?

//Stefan

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Aug 2007 12:34:14 +0200

Stefan Eissing wrote:
> Well, sending WWW-Authenticate along with 401 is a MUST. So, how would a 
> server send a 401 *without*

In theory it could invent an auth scheme name (and then not support it). 
For a client that would be indistinguishable from a real scheme that it 
happens not to support.

I just want to make sure that we don't end up promoting serving HTML 
login forms with 200, because 401 isn't allowed. Maybe the language for 
401 could be enhanced to state that if a server does require some kind 
of authentication, but does not support HTTP auth, 403 SHOULD be used?

Best regards, Julian

---

From: Hugo Haas <[email-masked]>
Date: Fri, 17 Aug 2007 09:48:58 -0700

> of authentication, but does not support HTTP auth, 403 SHOULD be used?

I don't think that people will necessarily return a 200 instead, but rather a 
403, a 400, or a custom 4xx error code.

As you mention, the debate seems to gravitate around whether it's OK to return 
a 401 with "WWW-Authenticate: Foo", Foo being a scheme which does not use the 
Authorization header to pass credentials (it's not clear to me from reading 
the specs as I mentioned in my original email).

It doesn't seem harmful: if  a client understands Foo, then it'll do the right 
thing, and if it doesn't know about Foo, then it won't be able to do anything 
in response to it, so it won't do anything wrong.

Hugo

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Aug 2007 13:38:50 +1000

http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 23 Aug 2007 00:27:11 +0200

> the specs as I mentioned in my original email).

While it's technically OK (it's a valid 401) I would certainly not
recommend inventing such authentication methods (I would not call them
schemes in this context) which do not make use of the Authorization
header.

The HTTP protocol is sensitive to if a request carries Authorization,
and object freshness and cachability is changed considerably for
responses to such requests. Authentication methods not using the
provided framework need to account for those aspects themselves by
adding suitable Cache-Control headers (i.e. "Cache-Control: private").

Regards
Henrik