On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer <jric...@mitre.org> wrote:
>> > OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
>>
>> Just curious. What use case would require that the access token is put
>> in the post body as opposed to an http header when accessing a
>> protected resource?
>
> If nothing else, it parallels the use case of a GET-style query
> parameter. It makes sense to have it be valid in both ways to allow
> developers to put the token in with whatever other parameters they're
> passing along. I've got plenty of use cases here for the query
> parameters: it's needed for cases where your client can't get any deeper
> into HTTP than "hey go fetch me this URL".

You can still use query parameters with POST.


> What use case says we shouldn't do POST parameters like that? A server
> wanting to do early-dispatch of a request was brought up, but that was
> only in the case of handling OAuth 1 and 2 simultaneously as I
> understood it. If a server's going to be doing dispatch on auth headers
> and query parameters already, it seems that it's got the wherewithal to
> parse a form-encoded body, too.

Parsing the body is not trivial. Some filters do not have access to it
(apache mod_redirect for example), some frameworks will allow you to
access it once and then commit to a format, a decision that cannot be
made by a filter (in Java see ServletRequest: getInputStream vs
getReader vs getParameter).


Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to