Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Tomek Stojecki <tstojecki@yahoo.com> Thu, 08 November 2018 11:19 UTC

Return-Path: <tstojecki@yahoo.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 4E5F6130E08 for <oauth@ietfa.amsl.com>; Thu, 8 Nov 2018 03:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 yS554QQqKeq3 for <oauth@ietfa.amsl.com>; Thu, 8 Nov 2018 03:19:16 -0800 (PST)
Received: from sonic304-21.consmr.mail.ne1.yahoo.com (sonic304-21.consmr.mail.ne1.yahoo.com [66.163.191.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387FA128CF3 for <oauth@ietf.org>; Thu, 8 Nov 2018 03:19:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1541675955; bh=/KOIWB8m7BUfEoF4KJiBFr/DuK+4FJ24tNn2EtPDCxY=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=eNWnOn2s7rUtGDLHv8R+U5SuSjtnGsQ1a97ghUsDUoDWANALfIfCFr3J4HQp5TaR/TAqZ2VKQspBVSxLDNxMEilA4BnrRWSgF5xEW9z2zj3/jKZaFr9+G8ZBZHVVbeT1YT1XvYzbpIFjysDn4K9WsDl/FBHE7IKUF0/NtAHHOH+cJ8eJbMnIZ4M2gBtjDmNjKCsFhkQ4c8IWSvMVEhUkI66LNN1yhAAO/1iP+boBmu6SypDyriMe/Q+0bU8PSSLIcCQgcZyp2/o36fiVRTraKLLEMuWEJ/x6jwetRVXIEbncDK2/A2qm+v3mj9KS2BzV4ge1zi9kB9NVk5liL/gUdQ==
X-YMail-OSG: fEk1_joVM1lD0KZ1i7lUqDEvPddh71K7Y9nXphQyrWT2QuhAtVyqbj_Y49NFWrs vfDmId99qRgUqRMBh5OTQAA0lhBhtbsqKjdGXbweukortfMNGn3k7Y1RAFsBU3pd4QFl1AApoujR mcUystasevtZnTvmqXFnvSvZ_IAsOZvAo0GlUShKR72.fdYZqGFgwrMk6WhVU3krDUwXyaPevLhn 4fuClz9539CBy_mxKodnh8d6cOkeqf_l_.LO0.ZTD7kVLW2qPI7uc60vZ1HB3_sWQv9rnHG.x9aB WL_LJeSDwtimGx7M5GS7Eh.JGEY5YN0SFCYIjrhQA.Kyxj0hL2z1oPC8GYZ1CcPKw5WmF87C9SAq e74w.HJYo8Ys5QH_YWy0zRyiTYBOS37cxgeOA7nPN4VVepVGrCqJ.j1oZwNqd78zD2v_s4DkNs6H 7PwW4xfBPqlmN8bcFCwYnguko3RPefbW4JTyZC8lv4yIzWyEG6YocJ2VpaJZqIUoCiPzy9K6r_h7 DGosnLVrLypOMehiKdLZ5.gCa2a_J4k1mrHhuwgoEWivK3m0QiVr_0fJY2BUJcsFQnMEaci.Wm9. Rlv3cyY7QpE0EsxL6f.M5cnEmQO3dtJlWLqV5mrysuKnks9SVc1VBRaj7oJMCc_rWDO1eXL4uDsQ PK8L1JWyQyKn0rppHxVCrW1ZOnb8K7z.8kUdcKrJAKAInt9Fj8F27VtF_GEvFkzozoODkr6yhBnK Su6R3oVelVIQFfnozsF5WrEYU6ufgmCkvuPAKOyyfcBiGajMvx.JELxLzh6kc6rxJuDJYxf6CALd TsLc.u3GszARQCN9HHnngW9sRZFthseXGoSa_EoJ1SkIhr.m_EeGGEFs2ECknk2L22VtqMy2.7SC 2DiXljnagZNWb7gUR7Rcvd1fpXm0Cl4qYi.0STh.NeZyaZkiwLLM2pUWFYZtxiasSrGTDQxxz7O0 CYgO5D06KrNvBFpy1kRGrRHG5dxGt8W9_JRMCJbxsWMh62YorB9cFnUQbn_37ObwLEs2MIe1pBwA -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Thu, 8 Nov 2018 11:19:15 +0000
Date: Thu, 08 Nov 2018 11:19:14 +0000
From: Tomek Stojecki <tstojecki@yahoo.com>
To: oauth <oauth@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Message-ID: <710899611.302780.1541675954453@mail.yahoo.com>
In-Reply-To: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.12721 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/D4h4Xj4zci8cduhDjFjgVf7qrpc>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 08 Nov 2018 11:19:18 -0000

Thanks for putting this together Aaron. 

Having read through the document, I am not as convinced that there is enough of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.

In section 7.8. the document outlines the Implicit flow disadvantages as following:

"- OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client."

If you use Code + PKCE with no client secret (public client) as it is being advocated, you can't verify the client either. PKCE is not for authenticating the client, it is there to provide a mechanism to verify inter-app communication, which occurs between a browser and a native app. There is no inter-app communication in implicit (everything stays in the browser), so no need for PKCE.

"- Supporting the implicit flow requires additional code, more upkeep and understanding of the related security considerations, while limiting the authorization server to just the authorization code flow simplifies the implementation."

This is subjective and can be easily argued the other way. I think one of the main selling points behind implicit was its simplicity. It is hard to argue (putting libraries aside) that making one redirect (implicit) requires more code, work, etc.. than making a redirect and at least two additional calls in order to get AT (plus CORS on AS side).

Further, in the beginning paragraph of 7.8, you mention that implicit gets the AT through the front-channel. Exchanging code for AT will also happen in the browser , where instead of a url you will have an xhr (and again, now we have cors)

Finally, how is the AT going to be refreshed? Are we allowing for long lived RT in the browser? I see that the document mentions CSP in 7.7, but doesn't the same apply to securing AT with Implicit?

Regrads,
Tomek Stojecki

On Tuesday, November 6, 2018, 10:55:40 AM GMT+1, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote: 





Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth