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

From: Bill Jung <[email-masked]>
Date: Thu, 27 Feb 2020 22:20:52 -0800

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 https://tools.ietf.org/html/rfc7662
In '1.  Introduction' section says,

*"This specification defines a protocol that allows authorizedprotected
resources to query the authorization server to determinethe set of metadata
for a given token that was presented to them byan 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 endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."*
So looks like a refresh token is allowed for this endpoint.

<https://www.pingidentity.com>
<https://www.pingidentity.com>
Bill Jung
Manager, Response Engineering
[email-masked]
w: +1 604.697.7037
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>
<https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf>

-- 
_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._

---

From: David Skaife <[email-masked]>
Date: Fri, 28 Feb 2020 14:54:53 +0000

Hi,

In additional to Bill's query, the use of the term "protected resource" in
the context of RFC7662 is quite confusing. As defined by RFC6749 (which
RFC7662 defers to for definition of the terms), the term "protected
resource" is defined as an "access-restricted resource" that a client can
request. In the context of RFC7662, it doesn't make sense for an
"access-restricted resource" to be making any requests to the introspection
endpoints - surely it is the resource server that is the intended consumer
of the introspection endpoints? This is also backed up by Section 4
(Security Considerations) of RFC7662 which reverts to using the term
"resource server" as the consumer of the introspection endpoints.
For example, in these quotes:
"However, since resource servers using token introspection rely on the
authorization
server to determine the state of a token.." and
"...the authorization server MUST determine whether or not the token can be
used at the resource server making the introspection call"

Apologies if I've misinterpreted something here, but if RFC7662 has a
different meaning for the term "protected resource" from RFC6749 then it
should be stated clearly within that document. I also agree with Bill's
observation that it doesn't make sense for a refresh token to passed into
an introspection request as a refresh token should only be accessible to
the client and the authorization server (neither of which are intended
consumers of the introspection endpoints).

Many thanks,
David Skaife

On Fri, Feb 28, 2020 at 9:59 AM Bill Jung <bjung=
[email-masked]> wrote:

> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Andrii Deinega <[email-masked]>
Date: Sat, 29 Feb 2020 23:12:31 -0800

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
<bjung=[email-masked]> wrote:
> 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>
> "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."
> "For refresh tokens,
> this is the "refresh_token" value returned from the token endpoint
> as defined in OAuth 2.0 [RFC6749], Section 5.1."
> 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
> [email-masked]