You should probably read the new edition of the spec. It will help you better understand the architecture. Not all the features of OAuth are valuable in a desktop application but you can very much still use OAuth. And the one call where a user is involved is not authenticated (using OAuth) so an OAuth 401 would not be applicable there anyway.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Zhihong > Sent: Monday, March 16, 2009 9:34 AM > To: OAuth > Subject: [oauth] Re: HTTP Status Code 401 > > > There is nothing wrong about the way OAuth uses HTTP auth from HTTP > perspective. However, it doesn't really work with the flow of OAuth. > Here are the few problems you will encounter if you want plug it into > HTTP Auth, > > 1. OAuth is for server-server call. It will be very hard to make OAuth > call from client (user-agent) because no secure way to keep secret > inside client. As a consumer, you always know if you need to use OAuth > before you make the call (preemptive mode in Apache HttpClient term). > You don't even know who the user is without OAuth. Even though you > could make a call first without OAuth and responds to WWW- > Authenticate, that doesn't improve user experience in anyway. It's > just an extra round-trip orchestrated by the consumer server. > > 2. OAuth is a 3-party dance. When a failure is returned from service > provider (like invalid sig or rejected token), consumer can't simply > respond to the 401 and continue the exchange. It needs to switch > context to send an error to user. If user tries again, it will > initiate a new transaction between consumer and service provider. > > HTTP Auth is a mechanism designed for browser. Even though it can be > used to authenticate server-server calls, OAuth doesn't seem to be a > good fit for this. > > Zhihong > > On Mar 13, 3:43 pm, Martin Atkins <[email protected]> wrote: > > Zhihong wrote: > > > > > 1. The protocol is intended for end-user and a browser extension/ > > > plugin is expected. > > > 2. The parameters are standard so it's easier to write a HTTP auth > > > handler. We used to have an one-legged protocol (getting access > token > > > with username/password) which sends username/password using Basic- > > > Auth. > > > 3. Interactivity or negotiation in the protocol. For example, IE/ > > > Firefox supports Kerberos using SPNEGO scheme. In which, 401 means > > > continuation of negotiation or more credential. 403 indicates a > > > failure and end of exchange. > > > > > As you can see, OAuth doesn't fit any of these use-cases. Using of > 401 > > > just causes unwanted confusion and overhead. > > > > At least in my implementation (yet to be released), we do use > > Authorization and WWW-Authenticate for OAuth along with the 401 > status > > code. If you send an unauthenticated request, the service responds > with > > 401 Unauthorized with a WWW-Authenticate header telling you to use > OAuth. > > > > As far as I can tell, this is consistent with what the HTTP spec has > to > > say about the WWW-Authenticate header, and fits into your point "2" > > above. In theory, you can send multiple WWW-Authenticate headers to > > declare support for multiple auth schemes, allowing you to support > basic > > auth for browsers in addition to OAuth. > > > > What's non-standard about the format of the OAuth messages sent via > > WWW-Authenticate and Authorization? To me they seem very similar in > > principle to the negotiation exchanges in SPNEGO. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
