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 -~----------~----~----~----~------~----~------~--~---
