> > 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". 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. -- Justin _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
