Eran Hammer-Lahav wrote:
>
> OAuth Core 1.0 5.2 implies that servers must support all three methods
> since clients will send parameters using one of three methods. The EC
> edition clarifies this a bit and says that clients must use one (and
> only one) of the three methods unless an extension is used.
>
> Section 4.2 does not list parameter deliver methods as part of the
> documentation, which reinforces the fact that servers are expected to
> support all three methods.
>
I can't fault your reasoning given the text of the spec as it exists today.
However, I do disagree that this is what the spec should say.
This is for a variety of reasons:
* The HTTP spec defines how Authorization interacts with caching, but
this is not defined for authentication credentials included in the URL
or in the body of the request. Therefore the two are not trivially
interchangable without carefully understanding the implications. The
OAuth specification completely ignores this issue.
* CGI programs running under Apache can't access the Authorization
header without server configuration trickery as I previously noted,
which means that such applications cannot implement OAuth correctly.
* Requiring servers to support arguments in the body has two troublesome
implications:
* By a strict reading of the spec, OAuth can't be used with GET,
OPTIONS or DELETE requests that have no body.
* OAuth can't be used with POST or PUT requests whose body is not
application/x-www-form-urlencoded, since OAuth does not define how to
encode the parameters in any other encoding. This is troublesome if, for
example, one wants to implement an AtomPub endpoint that uses OAuth.
(Which is actually my current use-case.)
* I can see no reasonable situation where a client should not be
technically able to support all three and therefore support whatever
subset of the three a server supports.
One exception is XMLHttpRequest, but as I noted in a separate message I
see no compelling reason to use OAuth over XMLHttpRequest, and even if
there were in that scenario the endpoint is likely to be designed with
XMLHttpRequest in mind, either being published by the same party as the
client HTML page or by being explicitly allowed via a mechanism like
crossdomain.xml, so such an endpoint would presumably choose to offer
the other mechanisms without it being a hard specification requirement.
> I think the confusion comes from the OAuth discovery spec which made
> this optional on the server side. So no, to be compliant with the spec
> as written today, servers must support all three methods and client
> should use the first method they can in the list (to apply the
> preference indicated).
>
"the first method they can" is an interesting turn of phrase, because it
makes me wonder in what situations a client *cannot* support any of the
three. By your wording above, no reasonable client should ever use
anything other than the Authorization header except in the weird case of
XMLHttpRequest.
I would like to see the specification changed to give the server the
ability to define which mechanisms are supported, and perhaps as you say
to strongly encourage the use of the Authorization header as a minimum.
I would also like to see more of a separation between the name and
meaning of the message arguments and how they are encoded, and to
address in some way the problem of generating a signature for a request
whose body is not application/x-www-form-urlencoded.
(So you can consider these to be late suggestions of OAuth FAIL! :) )
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
