Re: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials

Eran Hammer <eran@hueniverse.com> Mon, 16 January 2012 18:33 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9821F8603 for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 10:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level:
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+zenZmE52Td for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 10:33:15 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E0E8F21F85FB for <oauth@ietf.org>; Mon, 16 Jan 2012 10:33:14 -0800 (PST)
Received: (qmail 20460 invoked from network); 16 Jan 2012 18:33:14 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jan 2012 18:33:14 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 16 Jan 2012 11:32:58 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Todd W Lainhart <lainhart@us.ibm.com>, OAuth Mailing List <oauth@ietf.org>
Date: Mon, 16 Jan 2012 11:32:54 -0700
Thread-Topic: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials
Thread-Index: AcyC15XAuxW+S5alTsCFBIQ2Hm/JqxRpXlqQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C53B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <OF7AFAAB2C.12365054-ON8525791F.00716C91-8525791F.0072B001@us.ibm.com>
In-Reply-To: <OF7AFAAB2C.12365054-ON8525791F.00716C91-8525791F.0072B001@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 16 Jan 2012 18:33:15 -0000

Compliant - sure. Smart - well, that depends on the use case. OAuth provide a very flexible framework (mostly because we could not agree more on restrictions). This means you can follow the spec and produce bad or insecure implementation. The spec does warn against such issues, and in the case of unregistered clients, leaves that out of scope (which means, it doesn't need to address any security issues involved).

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Todd W Lainhart
> Sent: Tuesday, October 04, 2011 1:53 PM
> To: OAuth Mailing List
> Subject: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of
> client credentials
> 
> Although it seems like an abuse of the protocol, I'm wondering at Draft 22 as
> a mechanism for providing authorization without specifying client credentials
> (i.e. evaluating it as part of an SSO solution).
> 
> Specifically, I'm referencing the scenario/flow in Section 4.3 ("Resource
> Owner Password Credentials") where a callback_uri parameter is not
> specified. Assume that the client type is "public".
> 
> I'm also referencing Section 2.4, "Unregistered Clients", where the text says
> that the spec does not exclude the use of unregistered clients (with the
> appropriate disclaimers).
> 
> Under these conditions then, can I then expect a spec-compliant
> authorization server to not require client credentials when requesting an
> access token?
> 
>   -- Todd
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth