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

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 28 February 2016 15:44 UTC

Return-Path: <torsten@lodderstedt.net>
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 060AD1A1A99 for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 07:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 eGxg5f3tiKaT for <oauth@ietfa.amsl.com>; Sun, 28 Feb 2016 07:44:50 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 220B11A1ABC for <oauth@ietf.org>; Sun, 28 Feb 2016 07:44:47 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.106]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1aa3WW-0000Bn-LK; Sun, 28 Feb 2016 16:44:44 +0100
To: Thomas.Kupka@bmw.de, oauth@ietf.org
References: <788977955ECA61468DD6F0FF5CAC14DB1DB40F@SMUCM70B.europe.bmw.corp>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-ID: <56D315ED.6050209@lodderstedt.net>
Date: Sun, 28 Feb 2016 16:44:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <788977955ECA61468DD6F0FF5CAC14DB1DB40F@SMUCM70B.europe.bmw.corp>
Content-Type: multipart/alternative; boundary="------------010101040006020601060008"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/OwZr3QN-kEBMcONulXAk8UmWiy8>
Subject: Re: [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: Sun, 28 Feb 2016 15:44:53 -0000

Hi Thomas,

see comments inline.

Am 19.02.2016 um 12:14 schrieb Thomas.Kupka@bmw.de:
>
> 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
> inSection 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?
>

Yes, it does. The client shall use the authentication means it would use 
on the AS's token endpoint as well. And in the same way as public 
clients only identify themself in this use case, they are supposed to do 
the same at the revocation endpoint.

> 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.
>

Good catch :-) We discussed this when we went through WG review. The 
position we finally decided to take is: what is the worst thing an 
attacker could do on the revocation endpoint? It would revoke tokens in 
order to interupt the respective service for the resource owner. 
Requiring authentication will prevent this.

best regards,
Torsten.

> 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
> --------------------------------------------------------
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth