On Mon, Mar 16, 2009 at 9:34 AM, Zhihong <[email protected]> wrote: > > ... > > 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 doesn't have transactions -- there is no context to switch. In other words, from the viewpoint of the client, the first request results in an authorization denied error; it then needs to go off and do something else (possibly interacting with the user); then it retries with another request, which has no transactional relationship with the first from the viewpoint of the protocol or server. Of course the client might have a session going, but that's not part of the protocol. This is actually a great thing, as the last thing you want to do is to try to hold state on the remote server while you go talk to your user and possibly go through some kind of authorization/authentication/registration dance. > > 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. > It's actually a decent framework for server to server calls, as long as HTTP itself is a good framework for your server to server calls. > 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 -~----------~----~----~----~------~----~------~--~---
