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

From: Andrii Deinega <[email-masked]>
Date: Sun, 1 Mar 2020 10:46:18 -0800

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
https://tools.ietf.org/html/rfc7662#section-2.2. 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.

Regards,
Andrii

On Sat, Feb 29, 2020 at 11:12 PM Andrii Deinega
<[email-masked]> 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
> <bjung=[email-masked]> 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 https://tools.ietf.org/html/rfc7662
> > 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
> > [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth

---

From: David Waite <[email-masked]>
Date: Sun, 1 Mar 2020 20:38:45 -0700

I would expect the AS to invalidate the refresh token in this case, which would not require a refresh token mode nor necessarily any signaling back to the resource.

-DW

> On Mar 1, 2020, at 12:12 AM, Andrii Deinega <[email-masked]> wrote:
> 
> Hello Bill,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Andrii Deinega <[email-masked]>
Date: Sun, 1 Mar 2020 21:11:40 -0800

How would the authorization server know who actually uses the
introspection endpoint assuming that a protected resource and a client
application use the same credentials (client_id and client_secret)?

Regards,
Andrii

---

From: David Waite <[email-masked]>
Date: Sun, 1 Mar 2020 22:33:22 -0700

> application use the same credentials (client_id and client_secret)?

In the external context, you have a client accessing a protected resource with an access token. The client should treat the token as opaque, and RFC7662 makes no allowances for that client to introspect its tokens.

If you control both the client and protected resource, you may decide to short-cut and have them share credentials. However, the client logic still should never be introspecting the tokens.

The security considerations also say that you must prove the authentication of the protected resource, which I have interpreted to mean that access tokens used to authorize the call to the introspection endpoint must be issued to a confidential client - public clients cannot protect credentials to perform an authentication. You want to limit introspection to prevent denial of service and probing attacks, and to limit the amount of information on viable attacks conveyed if someone steals a token.

-DW

---

From: Bill Jung <[email-masked]>
Date: Wed, 4 Mar 2020 10:45:43 -0800

Yes, actually the term "protected resource" is awkward. It is the resource
server's jog to introspect tokens to protect those protected resources.

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

On Fri, Feb 28, 2020 at 6:55 AM David Skaife <
[email-masked]> wrote:

> 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:
>
>> 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.
>> 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
>> <https://tools.ietf.org/html/rfc7662>
>> *"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."*
>> *"For refresh tokens,this is the "refresh_token" value returned from the
>> token endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."*
>> <https://www.pingidentity.com>
>> <https://www.pingidentity.com>
>> Bill Jung
>> <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.*

-- 
_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: Bill Jung <[email-masked]>
Date: Wed, 4 Mar 2020 11:01:47 -0800

The question started when some RPs (client apps) asked that AS allow
introspection endpoint to RPs so that RPs can check their refresh
token's expiry. If AS allows this, which the spec is not clear about, then
AS needs to know if the request is coming from RP or RS so that AS can
allow the Access Token introspection to RS only. But then is that the right
thing to do even?

Surely some clarification will eliminate the time spent on unnecessary
discussion among developers.

On Sun, Mar 1, 2020 at 9:33 PM David Waite <david=
[email-masked]> wrote:

> In the external context, you have a client accessing a protected resource
> with an access token. The client should treat the token as opaque, and
> RFC7662 makes no allowances for that client to introspect its tokens.
>
> If you control both the client and protected resource, you may decide to
> short-cut and have them share credentials. However, the client logic still
> should never be introspecting the tokens.
>
> The security considerations also say that you must prove the
> authentication of the protected resource, which I have interpreted to mean
> that access tokens used to authorize the call to the introspection endpoint
> must be issued to a confidential client - public clients cannot protect
> credentials to perform an authentication. You want to limit introspection
> to prevent denial of service and probing attacks, and to limit the amount
> of information on viable attacks conveyed if someone steals a token.
>
> -DW
>
> >
> > Regards,
> > Andrii
> >
> >> I would expect the AS to invalidate the refresh token in this case,
> which would not require a refresh token mode nor necessarily any signaling
> back to the resource.
> >>
> >> -DW
> >>
> >>>> 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.
> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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]

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 16:42:34 -0500

Why would the client need to know the refresh token’s expiry? Can’t they just use the refresh token and see? Either way it’s a single round trip to the AS and the client gets the same answer with the same recovery code path.

 — Justin

> On Mar 4, 2020, at 2:01 PM, Bill Jung <bjung=[email-masked]> wrote:
> 
> The question started when some RPs (client apps) asked that AS allow introspection endpoint to RPs so that RPs can check their refresh token's expiry. If AS allows this, which the spec is not clear about, then AS needs to know if the request is coming from RP or RS so that AS can allow the Access Token introspection to RS only. But then is that the right thing to do even? 
> 
> Surely some clarification will eliminate the time spent on unnecessary discussion among developers. 
> 
>  <https://www.pingidentity..com/> <https://www.pingidentity.com/>	
> Bill Jung	
> [email-masked] <mailto:[email-masked]>	
> w: +1 604.697.7037	
> Connect with us:	 <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>	 <https://www.linkedin.com/company/21870>   <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>
> 
> On Sun, Mar 1, 2020 at 9:33 PM David Waite <david=[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 1, 2020, at 10:11 PM, Andrii Deinega <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > On Sun, Mar 1, 2020 at 7:38 PM David Waite <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> Hello Bill,
> >>> 
> >>> <bjung=[email-masked] <mailto:[email-masked]>> wrote:
> >>>> 
> >>>> In https://tools.ietf.org/html/rfc7662 <https://tools.ietf.org/html/rfc7662>
> >>>> So looks like a refresh token is allowed for this endpoint..
> >>>> 
> >>>> 
> >>>> Bill Jung
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> 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
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>> 
> >>> OAuth@ietf..org <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Bill Jung <[email-masked]>
Date: Wed, 4 Mar 2020 14:06:14 -0800

Yep, I agree. But that's just me agreeing with it. Unless the spec clearly
says it everybody will throw different ideas and use cases. That's why I
want the spec to clarify this.

On Wed, Mar 4, 2020, 1:42 PM Justin Richer, <[email-masked]> wrote:

> Why would the client need to know the refresh token’s expiry? Can’t they
> just use the refresh token and see? Either way it’s a single round trip to
> the AS and the client gets the same answer with the same recovery code path.
>
>  — Justin
>
> On Mar 4, 2020, at 2:01 PM, Bill Jung <
> bjung=[email-masked]> wrote:
>
>> >>>> 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.
>> >>>> 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>
>> attachments from your computer. Thank
>> you._______________________________________________
>> >>>> OAuth mailing list
>> >>>> [email-masked]
>> >>> OAuth@ietf..org <[email-masked]>
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Andrii Deinega <[email-masked]>
Date: Tue, 10 Mar 2020 14:11:18 -0700

Justin,

Aren’t these things considered as valid concerns?

The introspection endpoint allows to introspect a refresh token for
its consumers whether they are clients or RSs assuming they were
successfully authenticated using one or another way.

There are lots of projects which act like OAuth & OIDC proxies (or
just as HTTP request filters) for RSs and what they basically do is
check whether an access token is valid. The problem here, as I
described before, that an attacker or even a misbehaving client may
start to use a refresh instead of an access token which in the worst
case allows to have access to RSs for a lifetime of the refresh token.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-08
doesn't shed light on this thing too, at least for me, and even states
that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
protected resource to query an OAuth 2.0 authorization server to
determine the state of an access token and obtain data associated with
the access token." in the introduction section. Although, RFC7662
allows us to introspect two types of tokens with no issues.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 as
well as other documents I saw (for example "An Extensive Formal
Security Analysis of the OpenID Financial-grade API" at
https://arxiv.org/abs/1901.11520) neither cover this thing.

Could you please, clarify these things?

Regards,
Andrii

On Wed, Mar 4, 2020 at 2:06 PM Bill Jung
<bjung=[email-masked]> wrote:
>
> Yep, I agree. But that's just me agreeing with it. Unless the spec clearly says it everybody will throw different ideas and use cases. That's why I want the spec to clarify this.
>
>> On Sun, Mar 1, 2020 at 9:33 PM David Waite <david=[email-masked]> wrote:
>>>
>>> >>> specification.. Both token types can be revoked before the expiration
>>> >>> OAuth@ietf..org

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Mar 2020 10:20:25 +0100

Hi Andrii,

> On 10. Mar 2020, at 22:11, Andrii Deinega <[email-masked]> wrote:
> 
> Justin,
> 

As editor of this draft, I take the liberty to jump in here. 

draft-ietf-oauth-jwt-introspection-response-08 is not intended to be used in conjunction with refresh tokens, simply because there is no use case for refresh tokens. The objective is to provide RSs access token data with additional security properties by signing and encrypting it. This is typically required if the RS needs to proof that the AS provided this data to the RS. 

> https://arxiv.org/abs/1901.11520) neither cover this thing.

I assume because no-one could image RSs accepting refresh tokens. I also don’t see a use case for it and would strongly advise against it because it violates the security assumptions around refresh tokens. 

A client could theorectially use the token introspection endpoint and introspect a refresh token, but AS cannot do more than either not supporting refresh token introspection at all or provide a very small set of data for refresh tokens, basically active and scope. 

I don’t see how an attacker could utilize this to gain access to RSs but I agree this assumptions/advise needs to be clearly stated. 

best regards,
Torsten.