Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Torsten Lodderstedt <> Mon, 25 November 2019 16:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB74012098F for <>; Mon, 25 Nov 2019 08:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K1rMNa_U3iCE for <>; Mon, 25 Nov 2019 08:15:00 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 529E41208B0 for <>; Mon, 25 Nov 2019 08:15:00 -0800 (PST)
Received: by with SMTP id s5so18805813wrw.2 for <>; Mon, 25 Nov 2019 08:15:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m5kQ7QhGLICSXgTctSTK5zwlV8B3U6dBxi7f2ft8HMM=; b=YOMA5CYTJX2xDMkt1fbD6obqA0K1OIMa36ETaqyn0ojHl1ev3Wz2DxBfolmlviVOW3 2+ausiIMs8uREwftmg1BTdx5WSPuVeWWOBu/m+0YJRII+3rFYS4EfAsoq4cczlKzrbMg 0CBaWbQJtBFIqNmc7QDKo8mtdKWKOQErw7qwlanQ6/XmKRtJ/waxWVdACDlUJZ51Ts5h eRLnFQrpfykW4OUsZ1qySXOz9zH7dZNOpY63sU+HfjyLJDigA4Wtj4HlBobIMtqU3rqT H/YKBGCIYDAmCKJRqQ+7IRj7+6hh3n7mYtn9a9UnhqOpI7gF1B/LXvcd3z2LzNNpufne DWoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m5kQ7QhGLICSXgTctSTK5zwlV8B3U6dBxi7f2ft8HMM=; b=fjqzowPmlUWQwKWJQlBGswuBp9PtQtVHmK/fkhw0AMoJWrqYYqI3apXw8U3jxN4/PA J9Yh9c1fmc9t3Wj+N/KmmmLpXyaK9ZnnvVCSwq59MJrzhuxsvOLbTF6qinNUHY9NEXGV DhUI2j6g3DdV8rZUgIp8hFj7Frrp2jfo68tAXGhzs4I3IvnrOQo+YRr0wKLGI0S+Y70g kg9RFZpXJXTFzM9xTRled23Yw8YIjJzMg2VTI7DzSIisLDYhTOTUW1olqiF1dPzg0otd /W97gBF27yBzcDwrweiDgv3+IPrdFLHqmmOC76H60P5uFtW0Yy9GnDUJldXWrpQhPwrN 93aA==
X-Gm-Message-State: APjAAAU9VEVnfsC145eM7NG5GRJTCYp/ybcrmxFg8E9babQ9BLYeioNz sEgFryfUFRATMsqgj0PLKDe+YA==
X-Google-Smtp-Source: APXvYqxXljDZw7eAEIJ/UwAXjLYq6MhDhoKK83jr63Z7BslamyMLk6gc8Rk+ghtNwBglrnLggZBNPw==
X-Received: by 2002:adf:f688:: with SMTP id v8mr15688685wrp.147.1574698498124; Mon, 25 Nov 2019 08:14:58 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id a206sm9176448wmf.15.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2019 08:14:57 -0800 (PST)
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_95C4D7A4-E52F-4794-AE3D-48608A9EC6A6"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Mon, 25 Nov 2019 17:14:45 +0100
In-Reply-To: <>
Cc: Neil Madden <>, oauth <>
To: Aaron Parecki <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Nov 2019 16:15:03 -0000

> On 25. Nov 2019, at 17:06, Aaron Parecki <> wrote:
> I agree, the Facebook issue had nothing to do with extracting access tokens via a hack, it was entirely facebook’s fault for issuing access tokens improperly in the first place. They posted some amazing details on what happened on their website.
> If they couldn’t even get this right, it’s unlikely a sender constrained token would have helped here, and may have been bypassed just like the other three issues that led to the breach.
> > I tend to agree with your assessment. The simplest way with current OAuth is use of code+pkce+refresh tokens, narrowly scoped access tokens, and resource indicators to mint RS-specific, privilege restricted, short lived access tokens. 
> > 
> > Do you think we should spell this out in the SPA BCP?
> I agree that this is probably the best advice we can give. Ultimately people will still make mistakes like the ones that led to the Facebook issue, so all we can do is point people in the right direction.

It’s also softens the requirements since to would not require SPAs to have a PoP mechanism. 

I think that’s ok, since SPAs with all APIs and token handling in the browser will anyway not be the security critical ones. SPAs serving as frontend for security sensitive applications can cover API interactions in the backend (where we have practical measures available for sender constrained access tokens. 

> Aaron
> On Mon, Nov 25, 2019 at 6:08 AM Neil Madden <> wrote:
> On 25 Nov 2019, at 12:09, Torsten Lodderstedt <> wrote:
> > 
> > Hi Neil, 
> > 
> >> On 25. Nov 2019, at 12:38, Neil Madden <> wrote:
> >> 
> >> But for web-based SPAs and so on, I'm not sure the cost/benefit trade off is really that good. The biggest threat for tokens being stolen/misused is still XSS, and DPoP does nothing to protect against that. It also doesn't protect against many other ways that tokens leak in browsers - e.g. if a token leaks in your browser history then the threat is that the attacker is physically using your device, in which case they also have access to your DPoP keys. In the cases like the Facebook breach, where highly automated mass compromise was achieved, I think we're lacking evidence that PoP would help there either.
> >> 
> >> The single most important thing we can do to protect web-based apps is to encourage the principle of least privilege. Every access token should be as tightly constrained as possible - in scope, in audience, and in expiry time. Ideally at the point of being issued ...
> > 
> > I tend to agree with your assessment. The simplest way with current OAuth is use of code+pkce+refresh tokens, narrowly scoped access tokens, and resource indicators to mint RS-specific, privilege restricted, short lived access tokens. 
> > 
> > Do you think we should spell this out in the SPA BCP?
> I think that would certainly be a great start.
> -- Neil
> _______________________________________________
> OAuth mailing list
> -- 
> ----
> Aaron Parecki
> @aaronpk