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

Andrii Deinega <> Sun, 01 March 2020 18:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A6473A0B4C for <>; Sun, 1 Mar 2020 10:46:34 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 GWc-7iF00Z-R for <>; Sun, 1 Mar 2020 10:46:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D15883A0B4F for <>; Sun, 1 Mar 2020 10:46:30 -0800 (PST)
Received: by with SMTP id a5so8788634wmb.0 for <>; Sun, 01 Mar 2020 10:46:30 -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=iSrSN4Eg1VGjTrk+xaKpWGxONL0aYswrI6yWi8wDM+g=; b=L3anB0jm3F69rna+8DnzuKc+tp33AT1joUfUtN1TCmN0/2sHjnqMCgbdsa1PfpatOk pI5MG8me/w2twTIAfW9asH5qX1PCMow+PKT0621x2oiVTr34eF78wKRi7ypYCNXP4vQE FE+0ScU6Q4ns6sjLpJKkvVUyBrjQrKiTd5C52rleXWanYtgAH09WFnfxew0dqfAT3daj OOlhR90M9GV4pAgwz1KcARB6fROLRmAi5FAzyVkDPI4FptfiMMJ/qTR6eapepWrOA6ge zzgkPnloJGPydGaguQZkdbWpCtatV9JVOQlzPlStm5pA7oyybcgd/pqSspgwXVRTwauD ri2w==
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=iSrSN4Eg1VGjTrk+xaKpWGxONL0aYswrI6yWi8wDM+g=; b=e03D+MWOs30MFAaSwEtOS/rm6VE+50uO26jp/+TO0AmGy1EXHtz9M+d/G9wrCpGIbK 2OwwD7zFvmEbpL+Ufqa8+imA/+K/GaGGhtqK9X0XZVfvEOD97ovc0mIgfu3NkvMn+cbW YFoWPWG9yOaR6X2doCfnyce50AM6KqNuNX14jLYkLaa9LYcPHys3rh4lypdN6ITta0ar 7r9zgeTSpZFMHol+Bjg2AeOR/u2OdlS0kPznOnyrRb4wgKu3jNi8MDyfeGE5wI/cwUe1 P8bQwxGkEtwSf0X0vPTOqrL2iFw3oRFdU8V4MpAY3DZdjTpTun9T6AV2Gt20mDU6ZZV6 6/TQ==
X-Gm-Message-State: APjAAAXhUrTjwlaMXtsmSMkUCvC+LQvwJnK50eL6Eopg+OeMos3TkJ1S r8xh7SfPSe4rIxY6enXd8cEu+NiAfZfnIqsVq6iWVuJcrg/eQQ==
X-Google-Smtp-Source: APXvYqxLceDLMICmsrgqmY7HXaH6elXhFA6ntboPIUvFaRvFlWWoFNDEd7ZqKzSY+ZcBghLVh9MS7fNoeqScSvUP6Vc=
X-Received: by 2002:a7b:c76a:: with SMTP id x10mr15748097wmk.49.1583088389136; Sun, 01 Mar 2020 10:46:29 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andrii Deinega <>
Date: Sun, 01 Mar 2020 10:46:18 -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 18:46:34 -0000

I would like to add/clarify a couple of things. All our protected
resources share the same logic that uses the introspection endpoint in
order to verify whether a token is valid or not. We use the active
parameter for that. Although, we additionally check the token_type
parameter and its value. If this parameter isn't presented or its
value isn't equal to Bearer we identify this token as an invalid (only
access tokens can have Bearer in the token_type parameter as I
understand it). The main reason for this check is that I don't trust
developers of client applications which may use a refresh instead of
an access token by mistake or on purpose. I can rely on the token_type
parameter because there is a guarantee that our authorization server
returns it. This is an optional parameter according to Hence, this approach
may not work if we will decide to switch to another implementation of
the authorization server in our so-called OAuth "agents" and proxies
for our protected resources. I hope this scenario demonstrates why it
can be mportant to know when you deal with a refresh token on a
protected resource and I am unsure what other implementations of OAuth
client libraries and/or "introspect" filters do in this regard.


On Sat, Feb 29, 2020 at 11:12 PM Andrii Deinega
<> wrote:
> 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.
> --
> Regards,
> Andrii
> 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
> >
> >