Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

Andrii Deinega <> Thu, 11 February 2021 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 760A23A0BF1; Thu, 11 Feb 2021 13:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 VoqPwt09N5mn; Thu, 11 Feb 2021 13:43:07 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54C2F3A0962; Thu, 11 Feb 2021 13:43:07 -0800 (PST)
Received: by with SMTP id lg21so12342758ejb.3; Thu, 11 Feb 2021 13:43:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jqtj2fh1k7yhUgW60aQhvywemx9eOv0vquDs4vmCtjo=; b=NDoS9MtumDdpvzr6HHALlJLXRV+0b9VDCULXwkR7H3Xnd5yYqePbFDwB4P4dJAhw5d TqURffHRjlotxv63rruylKiwGSRR9L8CcaoL70pHqX8yXENQBSUcK2qGxvRQWgNBzoUt OupAwTbO2BwDPp3HmxhK3x5iFUDrdDCtELlQ4Dcn3arCBizg8+zKLmA8osKq/kaAnIfy 2GrvSJFOU+ZoHHmDF+FJf450Zxy1gBGVIOLKdZ1VqQ99Kc50Yx1Nc8ARvtwcyrgw0IC+ q7HPp2Ep4loZyrrcK3SeRT7KZdUSMsecK3y4H+d5SC1jTUlBoHiXNu2Od3vm/mZ5tDX7 TaiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jqtj2fh1k7yhUgW60aQhvywemx9eOv0vquDs4vmCtjo=; b=cytmuPnBzGbOoU6p7fHRA7tPHvxn9HYRh2NMimZPBT655FJnFr5Y7IRoorvhY1eWs6 IEHn/O5SLmXP6MO7K0VSoXi+GB4kDKiHmeOqfc8RQtuPp6oJxH2/aEXsXjYzEXpYPL+9 LMika9KNTXKDZlcyHGJ9xNy5Igh4Q9eWa5ex6a7HnXsKexk18ijxRajseis+2fGSDeF/ QviPdnqCnP/zm1sG5XseD2ysfu35/IzZ1V0jDp9Wyqhmv6WR70oH82tyC12PHsPRFD/4 2ta/4+SWgOZbmW+h4XledrmJc/BXPZDOUdUnsnV+W7qBjLJie1jGjimS9fJOcWkd/ioC vg/w==
X-Gm-Message-State: AOAM531/Vk60FgO7YSiRwWvE3fyxs4k+yr24AVduyUwR+3s6kl/uoHN1 dt9RKtk8It+yJ7Ti3iyUe1/O4QLFYxyTnKkrl/w=
X-Google-Smtp-Source: ABdhPJyE9biglpthHgKmze4SG0v2a5xWDy+E4VBoEtncH8PwnXwyZjg/TVyOyKCfCuD7X96HPPQwesxuY0duDtZdElo=
X-Received: by 2002:a17:906:ad98:: with SMTP id la24mr10574580ejb.315.1613079784319; Thu, 11 Feb 2021 13:43:04 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andrii Deinega <>
Date: Thu, 11 Feb 2021 13:42:53 -0800
Message-ID: <>
To: Neil Madden <>
Cc: oauth <>,
Content-Type: multipart/alternative; boundary="00000000000089ec6805bb16676d"
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce
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: Thu, 11 Feb 2021 21:43:10 -0000

Thank you for the response! Unfortunately, I'm still not convinced that
there is no need for nonce.

Based on the draft, I don't know how it's possible to achieve a “stronger
assurance that the authorizationserver issued the token introspection
response for an access token, includingcases where the authorization server
assumes liability for the content of thetoken introspection response
if we can't guarantee that a client will always get the response to its
initial introspect request, or in other words, old communications can be
never reused (the iat claim isn't going to be sufficient for that).

Let's put aside those attackers for a moment and say we experience some
awfully wrong caching issues that can happen anywhere between an AS and a
client... where the client gets a cached response for its previous requests
which isn't expected. How can it be prevented?



On Wed, Feb 10, 2021 at 12:15 AM Neil Madden <>

> On 9 Feb 2021, at 22:04, Andrii Deinega <> wrote:
> I still don't see how your #1 and #3 points mitigate the replay attack
> when an attacker somehow eavesdrops a successful response from an AS (yes,
> it's signed by a public key) and then starts to replay it for other
> requests from the same client.
> The point of #1 is that an attacker that has compromised the communication
> channel between the AS and client can do much more than replay
> introspection responses. In particular they can replace the AS’s public key
> with their own and then sign their own introspection JWTs, with whatever
> nonce in them that they like (they can easily see the nonce in the
> request).
> They can also steal access tokens and almost certainly also steal user
> session cookies and manipulate authorization responses from users to change
> the scopes that are approved for different requests.
> It’s absolutely essential that ASs and clients ensure the TLS connection
> between them is secure.
> The stated purpose of JWT introspection responses is for non-repudiation.
> It’s not intended as a replacement for TLS. Within that context “iat” is
> sufficient proof of freshness.
> The main problem here is that the client doesn't have a way to correlate
> the introspection response with the initial introspection request.
> In a properly secured environment this guaranteed by TLS (and even TCP).
> Regarding #2, it's true that there are many proxies that do this and that.
> In practice, you don't always have control over the infrastructure where
> you may run your AS as I was saying before.
> Right - so trying to solve this issue by replacing TLS with another
> technology that is just as susceptible to the problem is not a real
> solution.
> — Neil
> ForgeRock values your Privacy <>