Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Andrii Deinega <> Sun, 01 March 2020 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BE063A0918 for <>; Sat, 29 Feb 2020 23:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 l6Tz25wCSLpK for <>; Sat, 29 Feb 2020 23:12:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A5A83A091E for <>; Sat, 29 Feb 2020 23:12:44 -0800 (PST)
Received: by with SMTP id n7so552903wrt.11 for <>; Sat, 29 Feb 2020 23:12:44 -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:content-transfer-encoding; bh=B0sfCalBUlmmDvtPf6FqmGKWgtIjl5JZf6aoP1BfFhQ=; b=geB058TsBYKRKifwQtTlhj1RtN7WvESj1c6ttW36CjVmJDPnnv9zmEIPnCd8RQICog 3XC93wlbz9bm54SQ1dwqWhGRkuCZNM1ud0uExkhLL8Htp9JG6E9LWuwlmoda8p/a4vQ9 q8TChDkVd+0jLx02ffearPCV4uWpn9ZXftvQu/8KrEOfJTAAhUJZJSpHOgPBxSv5HSLN GISHa9tN6sYgHcCGMbZNqKudpFaco7ektShGqbFryFRQfx3VG9Y8WoZb42cCNZcAMs72 5wM4+/10B9C4jqxDdIoiYRO+lZql4Oj5sOjK7R6LEex2BPNWNmtP4VFqthW6YvxznQJN 2Ilw==
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:content-transfer-encoding; bh=B0sfCalBUlmmDvtPf6FqmGKWgtIjl5JZf6aoP1BfFhQ=; b=kW6Li1L4282/LJpujhkZO7VIKHvvRhP1tTxltDvyXLeVUyKRk7gD5fOwfuCPt4kOz6 ITb7MpnKw9ScueSrtuoO6g6+6qiyivW8H76d32cEnTYLyyhRUmdp1go0wI5H6H46wWz9 U1G/fjYh5xEscbcXs2GTkW55Ax9xCekq6WCzwGMcywAQQKq20qh1zm1gTt3iKAPXXRiX kpokagCbD9HWUCaPrArkkMoURxehZHMmDFftYmNzrvT7GpaxhRHuyjT+nYbFM9JXPAQL 4Yh2dpD14qPCCLHCvnkRfReEfnZWaiY2isP6SpRdf+gx7EQugROC5LuHnGmGfdV0JlYF T7gg==
X-Gm-Message-State: APjAAAV0YLoClmXCyC6KjlXR756yzmOaNrm5uJnX2IoVIb44GZnKitgs neUfYtJht1zIWTg4Qwt6jZdKndtG0bXy7GGYK3ZgdqFznoc=
X-Google-Smtp-Source: APXvYqzdIc7Mmdlwx2H3mSEHPqGNH5ZzOSCwWZjt2y8RU8nMhuHGfZMAf0XRTIwcqaDT10qXHZcESFqDDQkY0xaqh3I=
X-Received: by 2002:a5d:5301:: with SMTP id e1mr13949796wrv.44.1583046762777; Sat, 29 Feb 2020 23:12:42 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Andrii Deinega <>
Date: Sat, 29 Feb 2020 23:12:31 -0800
Message-ID: <>
To: Bill Jung <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?
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: Sun, 01 Mar 2020 07:12:47 -0000

Hello Bill,

I'm just thinking out loud about possible scenarios for a protected
resource here... It may decide to revoke a refresh token if a client
application tried to use it instead of an access token when the
protected resource is paranoid about security. In order to do that an
introspection response should include a non-standard parameter which
indicates that the requested token is refresh_token.

A user of the introspection endpoint should rely only on a value of
the active parameter (which is a boolean indicator) of the endpoint
response. This applies to both types of tokens. Note, the expiration
date, as well as other parameters, are defined as optional in the
specification. Both token types can be revoked before the expiration
date comes even if this parameter is presented as part of the
response. In my opinion, there are a number of reasons why this check
(for a refresh token) can be useful on the client application side.


On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
<> wrote:
> Hello, hopefully I am using the right email address.
> Simply put, can this spec be enhanced to clarify "Who can use the introspection endpoint for a refresh token? A resource provider or a client app or both?"
> RFC7662 clearly mentions that the user of introspection endpoint is a 'protected resource' and that makes sense for an access token. If we allow this to client apps, it'll give unnecessary token information to them.
> However, the spec also mentions that refresh tokens can also be used against the endpoint.
> In case of refresh tokens, user of the endpoint should be a client app because refresh tokens are used by clients to get another access token. (Cannot imagine how/why a resource server would introspect a refresh token)
> Is it correct to assume that the endpoint should be allowed to client apps if they want to examine refresh token's expiry time? Then the RFC should clearly mention it.
> Thanks in advance.
> <Details from the spec>
> In
> In '1.  Introduction' section says,
> "This specification defines a protocol that allows authorized
> protected resources to query the authorization server to determine
> the set of metadata for a given token that was presented to them by
> an OAuth 2.0 client."
> Above makes clear that user of the endpoint is a "protected resource".
> And under 'token' in '2.1.  Introspection Request' section says,
> "For refresh tokens,
> this is the "refresh_token" value returned from the token endpoint
> as defined in OAuth 2.0 [RFC6749], Section 5.1."
> So looks like a refresh token is allowed for this endpoint.
> Bill Jung
> Manager, Response Engineering
> w: +1 604.697.7037
> Connect with us:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list