You all might want to take a look at Thomas Broyer's cookie-auth HTTP auth scheme: http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00 for what he did to implement something reasonably similar.
I do think it would be nice if we don't abuse HTTP, which suggests we should define a new HTTP authentication scheme. So I would give a +1 to using HTTP 401 and doing some sort of a modification of the cookie-auth proposal to create the new scheme. Regards, - johnk On Apr 21, 2010, at 12:38 PM, Eran Hammer-Lahav wrote: > How about Marius' suggestion to use a 200 response? > > I'd rather not invent a new auth scheme that is used just to comply with HTTP > requirements for a 401... I think we either keep this simple(r) by using a > 400 or 200, or take another look at James' proposal for using Basic auth to > send the client credentials. At that point a 401 will be used when the client > credentials are wrong, and a 400 (or 200) when something else doesn't match > in the request (verification code, username/password). > > Can others voice their support/dislike for the various options? > > EHL > >> -----Original Message----- >> From: Robert Sayre [mailto:[email protected]] >> Sent: Wednesday, April 21, 2010 9:31 AM >> To: Eran Hammer-Lahav >> Cc: [email protected] >> Subject: Re: [OAUTH-WG] misuse of status code: 400 Bad Request >> >> On Wed, Apr 21, 2010 at 11:30 AM, Eran Hammer-Lahav >> <[email protected]> wrote: >>> We tried something like this approach before but the group consensus was >> that we should only have a single spec for now. >> >> Eran kindly pointed me at this survey: >> http://www.ietf.org/mail-archive/web/oauth/current/msg01214.html >> >> It doesn't look like very strong consensus to me, but I can see how the >> desire >> of everyone to call their thing "OAuth" can be a powerful motivator. :) >> >>> As for using Basic/Digest for flow authentication, that's a proposal made by >> James Manger which so far received little support (though no hard >> objections). >>> >>> I don't have a strong preference either way. >>> >> >> Well, regardless of how big the spec gets, this bit from 3.6.1.1. is a bug: >> >> HTTP/1.1 400 Bad Request >> Content-Type: application/x-www-form-urlencoded >> >> error=incorrect_credentials >> >> If you imagine a client trying to do something special with OAuth errors, >> there's nothing about this response that's self describing. >> Something like this layers much better: >> >> HTTP/1.1 401 Unauthorized >> WWW-Authenticate: OAuthDelegatation >> Content-Type: application/x-www-form-urlencoded >> >> error=incorrect_credentials >> >> On Wed, Apr 21, 2010 at 12:16 PM, Marius Scurtescu >> <[email protected]> wrote: >>> >>> At first 401 may seem like the perfect status code in this case, but >>> because there is no real challenge response, it probably is a bad >>> choice. >>> >> >> There certainly is, it just isn't an Authorization header. A client receiving >> error=incorrect_credentials would change the creds and respond, right? >> >>> >>> Some HTTP libraries will try to automatically respond to a 401 >>> challenge and if they are not configured to do so will generate noise >>> in the log files. I have seen Apache HttpClient doing that. >> >> People will write buggy OAuth clients too. Don't design around lame bugs in >> Apache HttpClient. :) >> >> -- >> >> Robert Sayre >> >> "I would have written a shorter letter, but I did not have the time." > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
