On Mar 13, 2009, at 8:47 AM, Zhihong wrote: [...]
> > I really like the way OAuth uses Authorization header so you can hide > OAuth clutter away from app data. However, the header is not used in > the context of HTTP auth. In OAuth, the Authorization header is always > unsolicited and not a response to 401+WWW-Authenticate. I don't think that's true. RFC 2616 says unequivocally that a server MUST send a WWW-Authenticate header in a 401 response, and describes that a client may respond with an appropriate Authorization header. OAuth 1.0 says, rather more weakly, "Service Providers MAY indicate their support for the extension by returning the OAuth HTTP WWW- Authenticate header upon Consumer requests for Protected Resources." It could certainly be argued that in correct usage of RFC 2616 (http://tools.ietf.org/html/rfc2616 ) and RFC 2617 (http://tools.ietf.org/html/rfc2617), OAuth should mandate that a WWW-Authenticate header is returned with a 401 response (ie. follow 2616). But I see nothing really incompatible in how OAuth specifies use of HTTP 401, and find that usage to be in the spirit of an HTTP-based authorization scheme. > So I think 403 > is more appropriate. From RFC 2616, regarding use of HTTP 403 Forbidden (http://tools.ietf.org/html/rfc2616#section-10.4.4 ): "The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead." Yes, "Authorization will not help." Not likely then that OAuth would work here at all. > > > For our internal APIs, we only use 2 status codes like OAuth, > > 400: Protocol error. It normally means a bug in the application and > it's intended for developers. > 403: All other errors. > > Now we use OAuth Java library, it returns whole bunch of 401s. It's > kind of messy but we can deal with it. It sounds like you need to implement an HttpClient-compatible handler for the OAuth authorization scheme, if you want to use HttpClient. - johnk > > > Zhihong > > > > On Mar 12, 8:41 pm, Eran Hammer-Lahav <[email protected]> wrote: >> What HTTP client do you use? >> >> EHL >> >> On 3/12/09 4:30 PM, "Zhihong" <[email protected]> wrote: >> >> I added WWW-Authenticate but now it complains unknown scheme. I >> disabled the HTTP auth and the warnings went away. >> >> I am new to OAuth and don't know the reason behind using 401. I just >> don't see the benefits of overloading HTTP authentication mechanism. >> >> Thanks! >> >> Zhihong >> >> On Mar 12, 7:27 pm, Eran Hammer-Lahav <[email protected]> wrote: >> >>> No. >> >>> Return 401 with the WWW-Authenticate header. >> >>> WWW-Authenticate: OAuth realm="your.server.example.com" >> >>> EHL >> >>> On 3/12/09 1:40 PM, "Zhihong" <[email protected]> wrote: >> >>> OAuth spec uses HTTP 401 (Unauthorized) as error code. We just >>> discovered that our HTTP client logs a warning (missing WWW- >>> Authenticate header) when receiving this status code because it >>> expects HTTP authentication when receiving this code. >> >>> Considering the special meaning of 401 in HTTP authentication, would >>> it be better to use 403 (Forbidden) instead? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
