Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

If, for your service, you want to use different means of authenticating clients, I see no reason why you can’t. Just ignore client_secret and do it your own way (it’s optional).

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Friday, April 16, 2010 9:52 PM
To: Eran Hammer-Lahav; 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*.
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:eran@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.Manger@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