Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard

Jeff Craig <> Mon, 31 August 2020 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDFE23A17CE for <>; Mon, 31 Aug 2020 10:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 s3yjyR3O3tY9 for <>; Mon, 31 Aug 2020 10:41:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A89783A17C5 for <>; Mon, 31 Aug 2020 10:41:02 -0700 (PDT)
Received: by with SMTP id s92so872951ybi.2 for <>; Mon, 31 Aug 2020 10:41:02 -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=NNfcVKp4jtUoXfEireLlUBKqqCTsTpAXWT+jC6ab1/U=; b=k6FShN6yw6wncTdFMiebaGSEBMqugrBdzB/9Lvw8ElgjbPP/E7MsThkHFEMKkHIcZE LlVdKel2FQmSggC56vCyF+hG8kuHrW3ElfKS5j6B+8yhqsMtltPplZ8eRqcOrV/vv5Qa q+uHBJl5+FIGSRMl4TKzA/qcyPMMqoZRXH/mr9rY80CcvOoLUKpuqh14kJb2Bjh+HpN/ x9SEpfafeshsu6qgmVjY1SXjYjCiLMDAZ3V+Ty8NRIVCJx9BiYRx8LkXBnZ/JtJN0ZtX myJ8YiNb/FZ88jcAPgmaewDWn/aU+6kY0/LwP7wEdGjpex3Ndj+czRO+SMGpAwNGBGGN hKvw==
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=NNfcVKp4jtUoXfEireLlUBKqqCTsTpAXWT+jC6ab1/U=; b=GgwtaKGPNUkp+MDfQbRqoz99e/hpfEka92uXQ7Lu/kiSzCaCh/8IvHukzEARhZW1lw A19NXhnFGtS382btQKkF3QlFhpESlb8zZO8N0OttfnD/KsduXmT+4bD7FQ7sqPB9JgaJ vXvqLN51SWFbeYFseboAAUNFAl0CMaShM8xFct2E+CIVP40j+lN8dsRBVw8WlRuLgGgM gNid692dU+1gBY8AO+XiPrdrUiCGsQvuNPKmrABWpXrZk5D03PHWk0yuDMUsnR4nzR58 sZBvg1qOClOPoBd7tghSfyvEsZgtIclmnPdjdc2s1XxlUWaiSbQixObjMJfUuKw0ZzIx bwLA==
X-Gm-Message-State: AOAM530eHiM3rvfh6IQRKCZbvK3PnADJ+bjDdgvY5RBc7jVlAW9BHzp7 00g0BQ3XYWGXynyxeQH01FNAT5OK5MeVS2MuNpHFEeR33lwAbw==
X-Google-Smtp-Source: ABdhPJwO6jbiizM/iAv1b44O9agHbe/WyHnf15jB5WkhTrziUWBlI47jVWGXEPjc6jhrPpVgfhFBAcrk0zVxZIGyt2Q=
X-Received: by 2002:a25:a441:: with SMTP id f59mr3820660ybi.42.1598895661516; Mon, 31 Aug 2020 10:41:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Jeff Craig <>
Date: Mon, 31 Aug 2020 12:40:50 -0500
Message-ID: <>
To: Neil Madden <>
Cc: Mike Jones <>, "" <>, oauth <>, Torsten Lodderstedt <>
Content-Type: multipart/alternative; boundary="000000000000f095b405ae2fe7ba"
Archived-At: <>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for OAuth Token Introspection) to Proposed Standard
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: Mon, 31 Aug 2020 17:41:07 -0000

I think that the argument is that token refreshing isn't as strong a signal
about usage patterns as introspection calls would be, which I agree with. I
also think that if a RS knows it's using an external AS, they've generally
accepted this information leakage. This is not to say it's not worth
mentioning in the document, but rather that I doubt it will significantly
move implementations one way or the other.

Generally speaking, I don't like JWTs as Access Tokens. They're verbose,
they leak information to clients that clients don't need, and if the RS
makes a mistake in their JWT validation, they can create security
vulnerabilities.  That said, I do think they are preferable to
Introspection at request time, and the RS's that I've worked with generally
don't want the overhead of Introspection on every usage of the token. I
generally argue a shared secret between the RS and the AS is a better
solution, but in my experience most cloud-hosted ASes don't offer that

For this cloud AS situation, I have been
tracking draft-ietf-oauth-token-exchange-19 as a means for RSes to setup a
Token Endpoint to convert the AS access token into a access token (w/o
Refresh) that the RS can accept, thus limiting Introspection to the Refresh
flow, but I don't currently have a RS interested in trying to try this
flow, but I think that it's a reasonable approach to limiting introspection
on every request to the RS, though it does add an additional point of
failure during the Token Refresh. This has the same leakage problem that is
under discussion here, obviously.

On Mon, Aug 31, 2020 at 3:34 AM Neil Madden <>

> But if you want to handle revocation (and you do), then the alternative is
> short-lived access tokens with frequent refreshing, which also informs the
> AS of activity. So is this any better?
> If an org running an RS decides to use a 3rd-party AS (eg cloud hosted)
> then there are privacy implications to that arrangement, regardless of the
> specific technology used for token validation.
> On 26 Aug 2020, at 22:16, Mike Jones <Michael.Jones=
>> wrote:
> I agree with Dick’s observation about the privacy implications of using an
> Introspection Endpoint.  That’s why it’s preferable to not use one at all
> and instead directly have the Resource understand the Access Token.  One
> way of doing this is the JWT Access Token spec.  There are plenty of others.
> The downsides of using an Introspection Endpoint should be described in
> the Privacy Considerations section.
>                                                        -- Mike
> *From:* OAuth <> *On Behalf Of * Dick Hardt
> *Sent:* Wednesday, August 26, 2020 9:52 AM
> *To:* Torsten Lodderstedt <>
> *Cc:*; oauth <>
> *Subject:* Re: [OAUTH-WG] Last Call:
> <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for
> OAuth Token Introspection) to Proposed Standard
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <torsten=
> <>>
> wrote:
> Hi Denis,
> > On 25. Aug 2020, at 16:55, Denis <
> <>> wrote:
> > The fact that the AS will know exactly when the introspection call has
> been made and thus be able to make sure which client
> > has attempted perform an access to that RS and at which instant of time.
> The use of this call allows an AS to track where and when
> > its clients have indeed presented an issued access token.
> That is a fact. I don’t think it is an issue per se. Please explain the
> privacy implications.
> As I see it, the privacy implication is that the AS knows * when* the
> client (and potentially the user) is accessing the RS, which is also an
> indication of *when* the user is using the client.
> I think including this implication would be important to have in a Privacy
> Considerations section.
> /Dick
> ᐧ
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list