> This has nothing to do with it. There is no PUT and DELETE or POST with > non-form body when *requesting a token*.
It is relevant. I don’t want to authenticate direct client requests *only* when they *request a token*. Clients might make any variety of direct requests unrelated to OAuth. There might even be other OAuth-related requests from clients to an authorization server in future (eg get meta data, or delete a token; even refreshing a token might be better as a GET). I want to be able to use the same client auth mechanism, and same client credentials, for all these calls. Some of these calls might be PUTs, DELETEs, non-form POSTs, GETs etc. even if requesting (& refreshing) a token is always a form POST. Hence client_secret as a POST parameter when requesting a token is a poor design. It should be perfectly valid (and not uncommon I expect) for a service to support OAuth for user delegation, but not use OAuth for making all direct client calls token-based — these address quite different issues. Other services might use short-term refreshable tokens when clients (on their own behalf) access less trusted “content” service, but will use “normal” auth when clients talk to the trusted account/authorization system. -- James Manger From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Saturday, 17 April 2010 12:58 PM To: Manger, James H; Luke Shepard; John Kemp Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints This has nothing to do with it. There is no PUT and DELETE or POST with non-form body when *requesting a token*. We need to do a better job not to confuse accessing protected resources with the flow calls. They are completely different. EHL On 4/16/10 7:02 PM, "James Manger" <james.h.man...@team.telstra.com> wrote: >> In either case, we should not restrict the access token URL to POST-only. >> A GET request is just as secure and can be much easier to write code for > If you are using GET, then refresh tokens and client secrets will end > up side by side in web server log files. These are exactly the sort of reasons why client authentication should be any "normal" auth scheme, and not an OAuth-special client_secret POST parameter. That fails for PUT, DELETE, and POST with a non-form body; and the security changes with GET. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
