Re: [OAUTH-WG] authorization code injection - draft-ietf-oauth-security-topics-13

Torsten Lodderstedt <> Fri, 15 November 2019 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8323D120891 for <>; Fri, 15 Nov 2019 07:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZU50f5_KO596 for <>; Fri, 15 Nov 2019 07:51:57 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2A24120801 for <>; Fri, 15 Nov 2019 07:51:56 -0800 (PST)
Received: by with SMTP id q70so10126103wme.1 for <>; Fri, 15 Nov 2019 07:51:56 -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=rRHhME1EVKL8O4BxE+qfHbUrJ8AEVreQbVvqv6HiVtE=; b=g/99799JMLEKoMnWV3SeMrl6L4VHap+A6PnpAppXP2FyBTBxa5VavKwPMjFN7Gi8Uy qrSdzCG6MCGD2rKJEqQG/iLHeQKZc23MmnuxjK6351Vb397zyMr+nJv9z6CRl2m6Sssz /wF2eLasa48JKYfxG8a1YjR0LqLKVU9QL+CDKoim6rpa0+VURtYZZuCZufdUGOtK+gdD RpAVLj7fjBobZivJmixqb8sZ2t8d6wokbXNb/x8C67kncomwPC+hg2yV7jUwSog+GK+7 ArABR/LXnUMMDPbDNhtMUk3Kfwb/JiS4eibJpEbaivO6D2YmBla5TLvyzWCZOBk08Th+ 6xXQ==
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=rRHhME1EVKL8O4BxE+qfHbUrJ8AEVreQbVvqv6HiVtE=; b=KGOU6xLXarM+yconTEwFKDvUcwRgwYrIO7NH2XaTSN5g47xoKAeXkKNbwQQkqMSzpe QAmOWQC6ihp6rq84mI1EXUitoFBRmjnkIkhRHlOidtv73iIlNQnZA0y/hr0oCIoaVcXq /bwbJb1VEV4BdsLteNrI62dc4zfTaWkkBW1r2BH1W72LuOF22kFGsi+OlMe/uxoas2jP Mi9BJTefW+XKWVEh1FI3r+RjoazHE7GqR9dW63kdyKE2xyyJwRSJbdN9acGIGJyuYGk+ cFeyUKvVFaXlV/ua14RL7rrqWHRfNcjlrrVhr7zUwerqRqnxMO4e3Dem0RyMRHQz8Q30 KMRw==
X-Gm-Message-State: APjAAAWC+jkJ4U7Ce6yCUGweiTo1NT1+I5hzMa6ZuIAyQ18MgROklXVd r9/lroPzFa/B2VALFndVkWAhMF/wd8EQRg==
X-Google-Smtp-Source: APXvYqxca4ogVvvqHb2Ly9FkXZKJ6CcmXOh1aeU7gfxSHSkX92w+zB8JNDgAth/hW/ZI8vUygxICmA==
X-Received: by 2002:a1c:dd45:: with SMTP id u66mr14940536wmg.12.1573833115064; Fri, 15 Nov 2019 07:51:55 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id w19sm10109074wmk.36.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 07:51:54 -0800 (PST)
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_F8795AD9-EB68-4686-A774-431F5F312C77"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 15 Nov 2019 16:51:52 +0100
In-Reply-To: <>
Cc: OAuth WG <>
To: Aaron Parecki <>
References: <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [OAUTH-WG] authorization code injection - draft-ietf-oauth-security-topics-13
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: Fri, 15 Nov 2019 15:52:01 -0000

Hi Aaron,

> On 14. Nov 2019, at 21:10, Aaron Parecki <> wrote:
> I read through the authorization code injection section
> but didn't see a mention of this explicitly...
> The guidance in 3.1.1 recommends using PKCE for confidential clients.

It’s a MUST for any client, not only confidential clients. 

"Clients utilizing the authorization grant type MUST use PKCE …"

> Section 3.1 says that  clients may use PKCE instead of "state" for
> CSRF protection, in which case "'state' may be used again for its
> original purpose".
> My worry is that without using a unique state value per request, it
> becomes less obvious that clients need to maintain state to avoid
> being tricked into exchanging an attacker's authorization code.

The PKCE verifier is a unique per request random value that needs to maintained in the state of the app as well. So beside it’s application for sender authentication and code replay detection, it also serves the role of state to detect CSRF. It just works differently in that the AS determines the response and the PCKE verifier don’t match and if that happens refuses to issue tokens.

> If the client is using PKCE, then this isn't an issue of exchanging a
> different valid authorization code. However it's an issue that the
> client may leave itself open to attackers tricking it into exchanging
> garbage authorization codes at the AS, possibly triggering rate limits
> or security flags at the AS.

You mean because it may send a PKCE verifier valid for the current transaction along with an infected code?

> There is a partial sentence that hits on the point in 3.1, "clients
> MUST only process redirect responses ... from the same user agent this
> authorization request initiated with". My worry is that this isn't
> enough guidance anymore if people are using non-random state values.

What is the relationship to the state value? The paragraph you cite is about mix up prevention and requires the client to memorize the AS it sent the user to. 

> If clients are required to use a random state value, then they are
> forced into a situation where they need to maintain state between
> requests, which then prevents this problem.

Same holds true for PKCE.

> Any thoughts on this? I am not sure exactly what the resolution should
> be. I suppose either still requiring a random value in the "state"
> parameter, or adding some guidance on how to link a redirect response
> with an authorization request.

Potentially it is not obvious enough, but the linking is (indirectly) implemented using the PCKE verifier.  

best regards,

> ----
> Aaron Parecki
> _______________________________________________
> OAuth mailing list