Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 18 April 2010 13:25 UTC
Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF873A69EE for <oauth@core3.amsl.com>; Sun, 18 Apr 2010 06:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.94
X-Spam-Level:
X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urp8JdPL6bzY for <oauth@core3.amsl.com>; Sun, 18 Apr 2010 06:25:35 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id BDB2A3A693C for <oauth@ietf.org>; Sun, 18 Apr 2010 06:25:34 -0700 (PDT)
Received: from p4fff1e7d.dip.t-dialin.net ([79.255.30.125] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1O3UUt-0001TC-Ds; Sun, 18 Apr 2010 15:25:15 +0200
Message-ID: <4BCB0837.1050506@lodderstedt.net>
Date: Sun, 18 Apr 2010 15:25:11 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Luke Shepard <lshepard@facebook.com>
References: <255B9BB34FB7D647A506DC292726F6E11257592315@WSMSG3153V.srv.dir.telstra.com> <C7EE71B8.32459%eran@hueniverse.com> <255B9BB34FB7D647A506DC292726F6E11257592327@WSMSG3153V.srv.dir.telstra.com> <2513A610118CC14C8E622C376C8DEC93D54D66DDB9@SC-MBXC1.TheFacebook.com>
In-Reply-To: <2513A610118CC14C8E622C376C8DEC93D54D66DDB9@SC-MBXC1.TheFacebook.com>
Content-Type: multipart/alternative; boundary="------------050901000702000805020906"
X-Df-Sender: 141509
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2010 13:25:37 -0000
from my point of view, the discussion is not necessarily about other means (== authn mechn). Shared secrets are acceptable for most cases. The discussion is about how client credentials are passed to the authorization server API (direct calls only). The proposal is to do it the HTTP authentication way. The spec recommends to use Oauth Authorization headers for securing service/API access via HTTP instead of API parameters. From my point of view, it is a matter of consistency to apply the same pattern (credentials in Authorization headers) to the OAuth authorization server API as well. From my point of view, the value of having the client_secret parameter is an interoperability baseline. Every library knowns how to perform client authn for OAuth. That's important!. You can achieve the same goal using a BASIC Authorization header + a lot of other advantages, which have already been pointed out in this thread. Additionally, WWW-Authentication headers could be used by the authorization server to signal the need for client authentication. In the current spec, I don't see a way to find out when client authn is required and when not. regards, Torsten. Am 17.04.2010 16:32, schrieb Luke Shepard: > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] Issue: Split the authorization endpoin… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… David Recordon
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… John Kemp
- Re: [OAUTH-WG] Issue: Split the authorization end… Justin Richer
- Re: [OAUTH-WG] Issue: Split the authorization end… Luke Shepard
- Re: [OAUTH-WG] Issue: Split the authorization end… Evan Gilbert
- Re: [OAUTH-WG] Issue: Split the authorization end… David Recordon
- Re: [OAUTH-WG] Issue: Split the authorization end… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… Marius Scurtescu
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt
- Re: [OAUTH-WG] Issue: Split the authorization end… Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue: Split the authorization end… Manger, James H
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt
- Re: [OAUTH-WG] Issue: Split the authorization end… Luke Shepard
- Re: [OAUTH-WG] Issue: Split the authorization end… Torsten Lodderstedt