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

"Brock Allen" <brockallen@gmail.com> Fri, 09 November 2018 22:07 UTC

Return-Path: <brockallen@gmail.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 A1CAB1276D0 for <oauth@ietfa.amsl.com>; Fri, 9 Nov 2018 14:07:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gnt9CvbwU1Fr for <oauth@ietfa.amsl.com>; Fri, 9 Nov 2018 14:07:36 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 EDEC21200D7 for <oauth@ietf.org>; Fri, 9 Nov 2018 14:07:35 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id r71so4368654qkr.10 for <oauth@ietf.org>; Fri, 09 Nov 2018 14:07:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=OZ+1w184oKEMgpErshFk5zgFHYiSphSKseFSs+ahiqQ=; b=d/5DH70RS/LZ+TgdQ1eBimpMnBwq0L8Z1kc/ygxxTHwzoouFTSTMO/nc4LvLJ58UAU 5YEp8NMs9HbIQdq8DidbJ1O9SLkXD2kWfA0aaPXvZAc3WPVyQ9iUHt5kEPfNpXNn1Cio 0Q0T4Ztid78z8SoeeH2IkDol0uRWearbE/BzLzb0qwAaMdfP99YL9zn1/EMc58QbYK3P tSV0EHCEd3Ba6pmAb4ZUXvoyheTrvPkaxQaitmDiVil0MzSidwxgN1XWv5Q0ebY2/CFA F7aJdJ7zBTMAmMPHI74uh+CWcE+EA3saAim8gghM8JKTTDZ8n47c3OwtTq2hPCVOhbak IwYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=OZ+1w184oKEMgpErshFk5zgFHYiSphSKseFSs+ahiqQ=; b=WEN+skUvqc6svkV6cp1bt+hy3XnguYTuI8sd/YaAAZbTg3Ocntt/puLAcRFfiW893x EYIINuo6b2D7iTZgYqEpPTD/+2IsJgCNmBMW9diCJvlfwqdhfZCwPVQZZGSBdrRwc5X5 vFFOr4eBxuygmRdvBpC5klttz1NiaJpiulCAy81J7VuX5pBcTbkO/TkiZyBZ14jMegJL hbztfxxemiY2mP1cgP+iNS9ovuiIoiu51FauiQX/4vI2zDsSYaBxK9yELLHkAW5jM0VD 8u3GeuTsdIerPeg/jwuXxY+cHJ27fSHv3wLjylhfza/QSsu5WZc4G3PRT3x9bcDIyJuO PQZQ==
X-Gm-Message-State: AGRZ1gJ/ZxemSX2BqhVy0I7KyGqv8xU7ii+lfbIATSZTaAz1nde37ScK pbqEWc5LDlvTlbqadBcu3rU=
X-Google-Smtp-Source: AJdET5eRmCN8yaDC7WAcLb1Ma8I9ncaEUWOgw7Q6WMc+t7Cv8w5R+3C8u8UmOcH+Egyuw/lUZGtwqA==
X-Received: by 2002:a37:aa0c:: with SMTP id t12mr9849805qke.358.1541801254796; Fri, 09 Nov 2018 14:07:34 -0800 (PST)
Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id m61-v6sm4716175qte.30.2018.11.09.14.07.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 14:07:33 -0800 (PST)
Content-Type: multipart/alternative; boundary="----=_NextPart_41506485.559191625583"
MIME-Version: 1.0
Date: Fri, 09 Nov 2018 17:07:31 -0500
Message-ID: <6339eebc-fcdc-4cd5-a129-1d950f4d7e45@getmailbird.com>
From: Brock Allen <brockallen@gmail.com>
To: Aaron Parecki <aaron@parecki.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>
Cc: oauth@ietf.org
In-Reply-To: <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com>
User-Agent: Mailbird/2.5.23.0
X-Mailbird-ID: 6339eebc-fcdc-4cd5-a129-1d950f4d7e45@getmailbird.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EViT9lzF_8zyAjuF2hSpMRyabVw>
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: Fri, 09 Nov 2018 22:07:39 -0000

> Finally, my last real concern (which is why I'm pushing back so much on code flow), is that this implies refresh tokens in the browser. My sense is that given the danger of this, the original OAuth2 RFC (via the implicit flow) was designed to limit the client's ability to obtain new access tokens based on the user's authentication session at the AS (via a cookie). Allowing refresh tokens now means that a successful attacker has unfettered ability to do this (beyond just an access token's lifetime). And yes, CSP is mentioned as a mitigation to protect the refresh token, but it was already necessary to protect the access token, so CSP is not the only mitigation. What's missing is strong guidance for token servers to provide mechanisms to limit the lifetime of refresh tokens for these high risk client scenarios. I have a suspicion that many existing token servers do not have such features, and this would imply more features mandated for the token servers (beyond PKCE for example).


And to expand upon this serious concern -- CSP only protects the current page from things like XSS. It does not protect every other page under your domain. IOW, your app using/storing refresh tokens (and access tokens) is trusting every other page on the domain to also be protected from XSS. At least an access token compromised this way has an expiration, whereas unbounded refresh tokens won't necessarily. This is why I am pushing for strong guidance around refresh token expirations, and this requires the token servers to implement and enforce this. 

So this sort of threat should possibly be used in the document to reinforce and motivate such guidance.

-Brock