[OAUTH-WG] Client authentication requirement

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 15 June 2011 17:27 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 3785221F857F for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 10:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8wxSDs3iT66 for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 10:27:23 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E864221F857D for <oauth@ietf.org>; Wed, 15 Jun 2011 10:27:22 -0700 (PDT)
Received: (qmail 26895 invoked from network); 15 Jun 2011 17:27:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2011 17:27:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 15 Jun 2011 10:27:19 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Wed, 15 Jun 2011 10:26:59 -0700
Thread-Topic: Client authentication requirement
Thread-Index: AcwrgIwZK4VJQHN3TIuODI9Bl2Ieew==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E986AF7@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234475E986AF7P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Client authentication requirement
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: Wed, 15 Jun 2011 17:27:24 -0000

Client authentication has been one of the main problem areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more confusing).

Because of the desire to allow any client type in any deployment environment, we ended up with a barely defined client authentication model. We offer password-based client authentication using HTTP Basic (and an alternative parameter), but leave it optional.

It has been suggested that by doing so, we have made the protocol security hard to define and harder to implement properly. The document was written largely with the requirement to use client authentication with any request to the access token endpoint. However, it does allow unauthenticated requests in section 3.

Are there any other client properties than the client's ability to authenticate with regards to security?

We have one grant type without client authentication (implicit), two with optional authentication (authorization code and username/password), and one with required authentication (client credentials).

I would like to go back to requiring client authentication for the access token endpoint, using HTTP Basic or other schemes. To leave the door open for clients incapable of authenticating to use the endpoint, we will add a security consideration section discussing the ramifications of using the access token endpoint without client authentication.

This suggestions is linked to the topic of refresh tokens which I'll post separately.

EHL