[OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps

<Thomas.Kupka@bmw.de> Fri, 19 February 2016 11:15 UTC

Return-Path: <prvs=85058ca23=Thomas.Kupka@bmw.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554F51B2E8D for <oauth@ietfa.amsl.com>; Fri, 19 Feb 2016 03:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maMwO2w3F27O for <oauth@ietfa.amsl.com>; Fri, 19 Feb 2016 03:15:02 -0800 (PST)
Received: from esa8.bmw.c3s2.iphmx.com (esa8.bmw.c3s2.iphmx.com [68.232.139.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5235D1B2E8A for <oauth@ietf.org>; Fri, 19 Feb 2016 03:15:01 -0800 (PST)
Received: from esagw2.bmwgroup.com (HELO esagw2.muc) ([160.46.252.38]) by esa8.bmw.c3s2.iphmx.com with ESMTP/TLS; 19 Feb 2016 12:14:56 +0100
Received: from unknown (HELO esabb4.muc) ([160.50.100.33]) by esagw2.muc with ESMTP/TLS; 19 Feb 2016 12:14:56 +0100
Received: from smuch56b.muc (HELO SMUCH56B.europe.bmw.corp) ([160.46.137.110]) by esabb4.muc with ESMTP/TLS; 19 Feb 2016 12:14:55 +0100
Received: from SMUCM70B.europe.bmw.corp ([169.254.6.66]) by SMUCH56B.europe.bmw.corp ([160.46.137.110]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 12:14:55 +0100
From: Thomas.Kupka@bmw.de
To: oauth@ietf.org
Thread-Topic: RFC 7009: Revoke Access Tokens issued to HTML5 web apps
Thread-Index: AdFrBR4Ruijl3823QaGFLNeRBqp/1g==
Date: Fri, 19 Feb 2016 11:14:54 +0000
Message-ID: <788977955ECA61468DD6F0FF5CAC14DB1DB40F@SMUCM70B.europe.bmw.corp>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.44.100]
Content-Type: multipart/alternative; boundary="_000_788977955ECA61468DD6F0FF5CAC14DB1DB40FSMUCM70Beuropebmw_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/EMzNzzvu73CtxTwwbVnaWH1U_y4>
X-Mailman-Approved-At: Fri, 19 Feb 2016 07:34:20 -0800
Subject: [OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 19 Feb 2016 11:15:53 -0000

Hi,

we use the OAuth 2.0 Implicit grant to issue access_tokens to client applications such as HTML 5 web apps that have no secure means to securely authenticating themselves. Even if the credentials would be obfuscated, any user could extract them from the HTTP requests their User Agent makes with minimal effort. Since RFC 7009 also talks about the usage of CORS to support User-Agent clients, however, I believe that these clients should be supported.

So I am having trouble supporting the revocation requirement in RFC 7009 which states:



   The client also includes its authentication credentials as described

   in Section 2.3. of [RFC6749]<https://tools.ietf.org/html/rfc6749#section-2.3>.

Looking at said section in in RFC 6749, it states:


   If the client type is confidential, the client and authorization

   server establish a client authentication method suitable for the

   security requirements of the authorization server.  The authorization

   server MAY accept any form of client authentication meeting its

   security requirements.

I am unsure whether "having no form of client authentication" conforms to the standard, can you comment on this?

As a side note, I wonder why client authentication for token revocations is required anyway, because if a client received a token by any legit means, it should always be able to revoke it, regardless of authentication. And if an unauthorized client 'stole' any type of token, revoking it should also be possible, since loss of service for the intended client should always be preferred over misusing the token.

Cheers,

Thomas


BMW Group
Thomas Kupka
Customer Data Management, FG-6301
GCDM Identity & Access Management
Bremer Straße 6
80807 München

Postanschrift:
80788 München

Tel: +49-89-382-54083
Mail: Thomas.Kupka@bmw.de<mailto:Thomas.Kupka@bmw.de>
Web:  http://www.bmwgroup.com/
--------------------------------------------------------
Bayerische Motoren Werke Aktiengesellschaft
Vorstand: Harald Krüger (Vorsitzender),
Milagros Caiña Carreiro-Andree, Klaus Draeger,
Friedrich Eichiner, Klaus Fröhlich, Ian Robertson,
Peter Schwarzenbauer, Oliver Zipse.
Vorsitzender des Aufsichtsrats: Norbert Reithofer
Sitz und Registergericht: München HRB 42243
--------------------------------------------------------