Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

Aaron Parecki <> Wed, 01 December 2021 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FBA83A064B for <>; Tue, 30 Nov 2021 16:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gKuO6_h5imTB for <>; Tue, 30 Nov 2021 16:05:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A0B13A064E for <>; Tue, 30 Nov 2021 16:05:23 -0800 (PST)
Received: by with SMTP id y16so28451788ioc.8 for <>; Tue, 30 Nov 2021 16:05:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KhghlRjjAoP2XsX/RQvq0WP/wbTuEkUz21ZE6/aN6tU=; b=MDbVTfz3EAlY/hC2kNhYT/Ix+hHBP5e+Yz8sbX+EDxMszRYTtEE8gUj8WQoq0MmZWy thC4GlVG/+5+NINnNEkni5TteTHEWviPN/gM0B3vlcf6rkR0QzD32YfomtEocPgRvOpJ K92Dx2bc2F2SPYe/5nrbNszj3G9EGZI2ZjiZhZNdpftfpZSqcJ3A2Q/jBU50nt0xNOMi uf8HeMjNMmGikcWjY/c33sRSGRe6/kN1oQ7ad6Uemx/ru8QrUYuA3YR2P+uhrtoESADR FKd4AkGYtSY68QZFG2PBQPzK96S6QNh0dSN5BZMt3+yDijCWu1H2ygMD92zxVHaXkoD1 yX9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KhghlRjjAoP2XsX/RQvq0WP/wbTuEkUz21ZE6/aN6tU=; b=eVumFUtPrfdd0yhIL/gS/Qj7JZ4F56vTHCcOFj0/g2vvl4zY0PwC/lYaQpl4SfMxYf l1cowBlaiGguvxcHcPA722Cv7kVILcj0mNo/7lX0FCczviqQi5Y4Xr+xoICV9IH5jxm4 sfl4otm2jxTPeGedSZq4TAFIE0y3CYYUBrmfDjLC0kKkhBXBQ0VgiyABTMuOCVcxrihc qRN+YUfEZGpc7VA3yqEYhKHGMxKuGwKxEX9eka/4bXPzDX+4GNLS0/AsWY6eSbtmUPAE nedTr8b0nKgJ4NTWrCCj0J91/Lqnqg4ZMC6MYCoSakzQg2LVyBXiMZornF0fiLJhTfVw d+Ww==
X-Gm-Message-State: AOAM531sy8haZDq7dUSDMJ2a0k1mcKHpb4t6YDK0A3PcwdJeM+43RweS s7uSBG8w51k3cDTqzs1PGiREYUnKfEHRHQ==
X-Google-Smtp-Source: ABdhPJzjCG0THTDj6Qxi8IPfHNx+tAoLV16FVhB/pcaBRD/P4OuEUG9Ain8SHtRyGo7IYWOGscFUbQ==
X-Received: by 2002:a05:6602:1604:: with SMTP id x4mr4137753iow.84.1638317120471; Tue, 30 Nov 2021 16:05:20 -0800 (PST)
Received: from ( []) by with ESMTPSA id q2sm12101680ilv.48.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 16:05:19 -0800 (PST)
Received: by with SMTP id a11so22963285ilj.6 for <>; Tue, 30 Nov 2021 16:05:19 -0800 (PST)
X-Received: by 2002:a92:d8cf:: with SMTP id l15mr4048805ilo.59.1638317118868; Tue, 30 Nov 2021 16:05:18 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Tue, 30 Nov 2021 16:05:07 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Neil Madden <>
Cc: Mike Jones <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e6553b05d20a6dc0"
Archived-At: <>
Subject: Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter
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: Wed, 01 Dec 2021 00:05:29 -0000

I tend to agree with Neil here. I'm struggling to see the relevance of this

It seems like the PDF writeup describes two possible reasons an attacker
could get access to the authorization code and PKCE code verifier.

1. The attacker has access to the logs of the token endpoint.
2. The attacker can intercept HTTPS connections between the client and AS
(VPN, corporate network proxy, etc)

For 1, the solution is to stop logging the contents of the POST body, and
secure your infrastructure. I don't think making the client jump through
extra hoops is a good solution if you are already logging more than you
should be or you don't trust the people who have access to the
infrastructure. If this really is a concern, I suspect there are a lot more
places in the flow that would need to be patched up if you don't trust your
own token endpoint.

For 2, if the attacker can intercept the HTTPS connection, then the
proposed solution doesn't add anything because the attacker could modify
the requests before it hits the authorization server anyway, and change
which DPoP key the token gets bound to in the first place. Plus, the
attacker would also have access to anything else the client is sending to
the AS, such as the user's password when they authenticate at the AS.

Are there other attack vectors I'm missing that might actually be solved by
this mechanism?


On Tue, Nov 30, 2021 at 12:40 PM Neil Madden <>

> Sadly I couldn’t make the DPoP session, but I’m not convinced the attack
> described in the earlier message really needs to be prevented at all. The
> attack largely hinges on auth codes not being one-time use, which is not a
> good idea, or otherwise on poor network security on the token endpoint. I’m
> not convinced DPoP needs to protect against these things. Is there more to
> this?
> The proposed solutions also seem susceptible to the same problems they
> attempt to solve - if an attacker is somehow able to interrupt the client’s
> (TLS-protected) token request, why are they somehow not able to
> interrupt/modify the (far less protected) redirect to the authorization
> endpoint?
> — Neil
> On 30 Nov 2021, at 20:15, Mike Jones <
>> wrote:
> As described during the OAuth Security Workshop session on DPoP, I created
> a pull request adding the dpop_jkt authorization request parameter to use
> for binding the authorization code to the client’s DPoP key.  See
> This is an alternative to,
> which achieved this binding using a new DPoP PKCE method.  Using this
> alternative allows PKCE implementations to be unmodified, while adding DPoP
> in new code, which may be an advantage in some deployments.
> Please review and comment.  Note that I plan to add more of the attack
> description written by Pieter Kasselman to the security considerations in a
> future commit.  This attack description was sent by Pieter yesterday in a
> message with the subject “Authorization Code Log File Attack (was DPoP
> Interim Meeting Minutes)”.
>                                                        -- Mike
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list