Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08

Daniel Fett <> Sat, 19 May 2018 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 052D712D87D for <>; Sat, 19 May 2018 06:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 NmFTDSFVkCLX for <>; Sat, 19 May 2018 06:10:00 -0700 (PDT)
Received: from ( [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5CD512D87B for <>; Sat, 19 May 2018 06:09:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40AF27CE3C; Sat, 19 May 2018 15:09:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i=; t=1526735395; x=1528474196; bh=xXxSxmh4e3 d4/uNNLfFH81BLesisSYfV1RnAWfwb9pE=; b=P09CWx07J6qMMZH1/7aMohfQYz /khwAMMYLAhcsOdUDc8pK+8npzeXACcP55yzyGh/3PfhocKfY81s0V9ZBywTe5G+ qdy0/Ekwv/Pu2+PPl/CSEKKkqP+F6ivLHMVkjSL84zDRPKRy4XM4Awx4CEy1jFBY NELXN31BlSuxZ1/TDJt0EbVrruf7QSUE/jSuI0UBwde4U/QD9nrOjoZvG+Lhb6xX qu3fx0AdyApS4U0UuhPKtEqsQPjoUvRy8moHAsn3tp5JSDBxEEA73Dzf20p5yJcp oH1lqQ/p9IdiFNczQxQuj8Ro1WT63fd3QuNB1ZU6xODq1K6PVJLtbpbfCt3Q==
X-Virus-Scanned: USTUTT mailrelay AV services at
Received: from ([]) by localhost ( []) (amavisd-new, port 10031) with ESMTP id jS4EOghxzcFL; Sat, 19 May 2018 15:09:55 +0200 (CEST)
Received: from [IPv6:2001:16b8:2262:9000:d4d:9d5d:9dd2:fbae] ( [IPv6:2001:16b8:2262:9000:d4d:9d5d:9dd2:fbae]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA; Sat, 19 May 2018 15:09:54 +0200 (CEST)
To: John Bradley <>, "" <>
References: <> <>
From: Daniel Fett <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Sat, 19 May 2018 15:09:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3334613BB36D2E069AE73BF6"
Content-Language: de-LU
Archived-At: <>
Subject: Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 May 2018 13:10:03 -0000

Am 18.05.2018 um 18:20 schrieb John Bradley:
> I am not against having "as" as REQUIRED.
> While we are at it should we recommend that rfp be single use?  
If the state JWT is *not* signed and the client has no other means to
check the integrity of the JWT (e.g., by storing a copy in the browser's
session), rfp MUST be single use, where single use means that once a new
authorization request has been sent, all old "rfp" values (for that
browser session) become invalid.
(Rationale: The state reuse attack across AS would still be possible,
since an attacker could just replace the "as" value in an unsigned JWT.)

If the state JWT is signed and "as" is contained in the JWT, rfp does
not need to be single use in this sense.

To prevent defense-in-depth against the usage of leaked of state values,
in both cases, a state value that has once been accepted at the
redirection endpoint SHOULD be invalidated for future uses. In the the
case of an unsigned JWT, this means that a specific rfp value SHOULD
only be accepted once. If the JWT is signed, it would be sufficient to
memorize the hashes of used JWTs or their jti values, and decline JWTs
with the same hash/jti. (SHOULD since this is impossible for stateless

(Overall, it seems like not signing state JWTs is not a good idea.)

> This draft hangs around as a ID and probably is not read by most
> people.  
> We may also want to mention it in security topics if we haven't. 
I will check the status there.
> I need to update this in the next couple of weeks to keep it from
> expiring anyway. 
I took a cursory look at the draft and I see two more issues:


> The "as" claim if present MUST correspond to the URI endpoint
registered as the "redirect_uri" for that AS.

This wording is not sufficient:
- The AS must be the expected AS (if there are means to check that, for
example the browser session).
- The redirection URI on which the authorization response was actually
received matches the "as" value.


> The client parses it as a JWT.  It then verifies the signature of the
JWT (if signed)

The client should check the signature if it expects the JWT to be
signed, not only if the received JWT is signed. I may be nitpicking
here, but developers should not be lead to believe that "if
signed(received_jwt): check_sig(received_jwt)" would be a good
implementation choice.

- Daniel

SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434