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