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

Andrii Deinega <> Thu, 18 March 2021 05:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EF603A1FEC; Wed, 17 Mar 2021 22:33:51 -0700 (PDT)
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 UGbL9YrUPe0L; Wed, 17 Mar 2021 22:33:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 367BB3A1FEB; Wed, 17 Mar 2021 22:33:49 -0700 (PDT)
Received: by with SMTP id hq27so1959868ejc.9; Wed, 17 Mar 2021 22:33:49 -0700 (PDT)
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=Gto5Jt5VsY7SHhJZ7v2k8LRl3atNvMcYJ2lP0D5ojuY=; b=rTJOkUdi74sru5MzRzMeLhAXuMSt9DuYh7Y60JGXFphXRnBaU4lUxsZH4YaRrmFeUv 5mcUBUKJax+EhpVfZqF489XSBgebZKCubMLfmFY2FKgYV9TX21IJ/HHKVjExm+9wLSAo GbbAXPUNu+y1Nxh0y6/p67wBwco4Bhlxgknk5J2EaSyudcRNyn4kZIkHAHvRU3eGBD/8 pg+G3wjiriey47wR96GNq8A7/rMFAFCYIS98Tr9P/vCPVs99F0bZZC/bkO5iYj+nsHny er6dIgvm6ExHmwumZN0414JVBxgt/lBFDUfw4y23P1b7HOqLZrje1M5OwrIhG0K4xLL3 +Azw==
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=Gto5Jt5VsY7SHhJZ7v2k8LRl3atNvMcYJ2lP0D5ojuY=; b=eLqPOH+HzdE9/GVCMDQWLKjGAO8j7IWfOShtw9YdHeJdJdiLRutSGbdRxYCXE11uCX Tgktqllu0CEK0SZAkdaWXALterBW27qv9P0FCfmoSQ93U3b2tjkuyWhXfhOnHikie8wt yJjJEF6Qt16VtHjX9SUKfoDD/nY4bxtQLQVHE+BzbBD/jl+AyUysboX3IaghL93nARK4 2UJBPci9XSxtt/6HgNk2QaGSqAiIets5zdDRA9Xyn5BrFKPvFc+wE2K52KMYoyhsHqVH rX4Bcvxzg+XE7TBcYkL2FTiVcrJ/ujvtpr98WGYV2ondZuuWTprI0whFh/AqbttvsoBp rm2Q==
X-Gm-Message-State: AOAM532p0Yu91nxRaSZTHk08kGfh22joLkj1ylJ8YgTIF34EUGt7Fc/y avOamH0jAD5RLlndlBwyyOD09631Ki57YRa6xTw=
X-Google-Smtp-Source: ABdhPJzjmDjeF8Qc87WsC907pf4KlLUIFemhKAYWSdW/IwTyCl3cJbdBNX3ymwpaKHnhsUC4QS2qaCF9lGKVjLDybT8=
X-Received: by 2002:a17:906:7f84:: with SMTP id f4mr38044384ejr.525.1616045626451; Wed, 17 Mar 2021 22:33:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andrii Deinega <>
Date: Wed, 17 Mar 2021 22:33:35 -0700
Message-ID: <>
To: Neil Madden <>
Cc: oauth <>,
Content-Type: multipart/alternative; boundary="00000000000081694c05bdc8f1ba"
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, 18 Mar 2021 05:33:51 -0000

The Cache-Control header, even with its strongest directive "no-store", is
pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext
Transfer Protocol: Caching).

This directive is NOT a reliable or sufficient mechanism for ensuring
> privacy.  In particular, malicious or compromised caches might not
> recognize or obey this directive, and communications networks might be
> vulnerable to eavesdropping.

Regarding TLS, I've mentioned that we don't always have the luxury to see
what is going on with the infrastructure. A bright example would be an AS
implemented as a serverless application and hosted by one of the cloud

As for,

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.

Following your logic, other RFCs such as 8555 (Automatic Certificate
Management Environment) went the wrong way with their mandatory anti-replay
built-in mechanism in quite similar circumstances.


On Fri, Feb 12, 2021 at 12:09 AM Neil Madden <>

> On 11 Feb 2021, at 21:43, Andrii Deinega <> wrote:
> 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
> <,server%20issued%20the%20token%20introspection%20response>”
> 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).
> The whole point about liability is being able to establish it after the
> fact. A nonce is only meaningful within the initial interaction and so is
> no help at all for establishing liability.
> 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?
> 1. TLS. 2. Cache-Control.
> — Neil
> ForgeRock values your Privacy <>