I support the idea to use standard HTTP auth mechanisms for
authentication on the authorization server endpoint. From a design
standpoint this is just an API - which we cannot to protect via OAuth
tokens because it issues these tokens. But we can use HTTP standard
authorization mechanisms (and headers) as BASIC or DIGEST to
authenticate the callers. This gives implementations the option to use
other mechanisms (like SPNEGO or CERT). And as James pointed out, there
might (will in our case) other requests on this endpoint used to provide
additional services via other HTTP methods, e.g. DELETE. Moreover,
standard authn modules (as in HTTPClient) can directly be used to
implement access to OAuth authorization servers.
I would recommend to separate functional API parameters, like callback
url, and authorization data.
regards,
Torsten.
Am 17.04.2010 06:52, schrieb Manger, James H:
> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
