Subject: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

From: Andrii Deinega <[email-masked]>
Date: Sat, 6 Feb 2021 23:41:57 -0800

Hi WG,

draft-ietf-oauth-jwt-introspection-response-10 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." which is true.
Although, according to RFC7662, the introspection endpoint allows to
introspect a refresh token as well. Hence, the question I have is how will
a token introspection response look like when the caller provides a refresh
token and sets the "Accept" HTTP header to
"application/token-introspection+jwt"?

I expect there will be no differences, right?

If so, I suggest to

   1. replace "a resource server" by "the caller" in section 4 (Requesting
   a JWT Response)
   2. change "If the access token is invalid, expired, revoked" by "If a
   given token is invalid, expired, revoked" in section 5 (JWT Response)

If not, my suggestion would be to clarify what the AS should do when it
asked to introspect the refresh token in general and additionally, what
should happen in the same case based on the type of the caller from the
AS's point of view.

Regards,
Andrii

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 7 Feb 2021 13:14:05 +0100

Hi Andrii,

thanks for your post. 

The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality. 

I’m not sure whether there are similar use cases if a client introspects a refresh token. What is your use case?

best regards,
Torsten.  

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <[email-masked]>:
> 
> Hi WG,
> 
> draft-ietf-oauth-jwt-introspection-response-10 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." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/token-introspection+jwt"?
> 
> 	• replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response)
> 	• change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
> 
> Regards,
> Andrii
>

---

From: Andrii Deinega <[email-masked]>
Date: Sun, 7 Feb 2021 12:30:10 -0800

Hi Torsten,

thank you for your response.

My use case is pretty straight forward

An OAuth client queries the AS to determine the active state of an access
token and gets the introspection response which indicates that this access
token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of a refresh
token and gets the introspection response which indicates that this refresh
token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of an access
token and gets the introspection response (JWT) which indicates that this
access token is active (using this draft).

Now, an OAuth client queries the AS to determine the active state of a
refresh token (using this draft)... How will the introspection response
look like assuming that the client provides the valid refresh token and
technically, nothing stops it from doing so.

Regards,
Andrii

On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <[email-masked]>
wrote:

> Hi Andrii,
>
> thanks for your post.
>
> The draft is intended to provide AS and RS with a solution to exchange
> signed (and optionally encrypted) token introspection responses in order to
> provide stronger assurance among those parties. This is important in use
> cases where the RS acts upon the introspection response data and wants the
> AS to take liability re the data quality.
>
> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega <[email-masked]
> >:
> >
> > Hi WG,
> >
> > draft-ietf-oauth-jwt-introspection-response-10 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." which is
> true. Although, according to RFC7662, the introspection endpoint allows to
> >       • change "If the access token is invalid, expired, revoked" by "If
> a given token is invalid, expired, revoked" in section 5 (JWT Response)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 7 Feb 2021 22:58:19 +0100

Hi Andrii,

> Am 07.02.2021 um 21:30 schrieb Andrii Deinega <[email-masked]>:
> 
> 
> Hi Torsten,
> 
> An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).
> 
> An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).
> 
> An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).
> 
> Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.  I also think using token introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource. 

I‘m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.

> 
> Regards,
> Andrii
> 
> 
>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <[email-masked]> wrote:
>> Hi Andrii,
>> 
>> thanks for your post. 
>>

---

From: Warren Parad <[email-masked]>
Date: Mon, 8 Feb 2021 00:56:20 +0100

>
> I‘m therefore leaning towards explicitly stating in our draft that it is
> not intended to be used with refresh tokens.

I'm not following, why explicitly state that it isn't intended. If an AS
wants to provide a similar JSON response to a query with the refresh token,
why not encourage that?

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.

On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> why should the state be provided as JWT?I think the plain JSON response is
> sufficient in that case.  I also think using token introspection for
> checking the state of a token from the client side has limited utility. The
> definitive decision is always made when the client tries to access a
> resource.
>
> I‘m therefore leaning towards explicitly stating in our draft that it is
> not intended to be used with refresh tokens.
>
> best regards,
> Torsten.
>
>
> Regards,
> Andrii
>
>
>> >       • change "If the access token is invalid, expired, revoked" by
>> "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
>> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 8 Feb 2021 03:18:45 +0100

> Am 08.02.2021 um 00:56 schrieb Warren Parad <[email-masked]>:
> 
> 
> I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that?

Why should we encourage it? 

> 
> 	
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement Authress.
> 
> 
>> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=[email-masked]> wrote:
>> Hi Andrii,
>>

---

From: Warren Parad <[email-masked]>
Date: Mon, 8 Feb 2021 10:07:19 +0100

It doesn't work that way. You suggested to add language to the draft, that
means the burden of proof is on you to justify adding it.

Otherwise I could just say why not?

And I can go stronger, what's the purpose of nho introspection endpoint at
all, and why encourage sending access tokens to the AS?

Even if you can justify access tokens, there currently isn't evidence
provided why we should explicity discourage.

On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt <[email-masked]>
wrote:

> Implement Authress
> <https://www.google.com/url?q=https://authress.io&source=gmail-imap&ust=1613346997000000&usg=AOvVaw267Z448csTGn3F6REIQ9pT>
> .
>
>
>> An OAuth client queries the AS to determine the active state of an
>> access token and gets the introspection response which indicates that this
>> access token is active (using RFC7662).
>>
>> An OAuth client queries the AS to determine the active state of a
>> refresh token and gets the introspection response which indicates that this
>> refresh token is active (using RFC7662).
>>
>> An OAuth client queries the AS to determine the active state of an
>> access token and gets the introspection response (JWT) which indicates
>> that this access token is active (using this draft).
>>
>> why should the state be provided as JWT?I think the plain JSON response
>> is sufficient in that case.  I also think using token introspection for
>>> > If not, my suggestion would be to clarify what the AS should do when
>>> it asked to introspect the refresh token in general and additionally, what
>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613346997000000&usg=AOvVaw3ZHWt08dlcHAgxyfj2hrsX>
>>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 8 Feb 2021 17:13:31 +0200

At first it may appear that allowing refresh tokens at the introspection
endpoint may be a logical thing to do, but in practice there are issues
with that and from an OAuth 2.x perspective it's not easy to justify.

If the point is to let clients check what authorization they have been
given OAuth 2.0 already provides a std way to do that - in the access
token response - the "scope" parameter:

https://tools.ietf.org/html/rfc6749#section-5.1

RAR has a similar parameter:

https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1

If the point is to find if a refresh token is still valid - this can be
found out by simply using it. Allowing refresh tokens to be introspected
can also create a conflict with the sec recommendation to rotate them.
So thus it may be a better idea to not let clients assume too much about
them.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2

If the AS is going to expose refresh token data to a client it will also
have to make a careful judgement what data it exposes.

https://tools.ietf.org/html/rfc7662#section-2.2

For instance "sub". OAuth 2.x in the relation between AS and client
actually has no concept or definition of subject / end-user identifier.
And this is done for a good reason, because it's not a user
authentication protocol. OIDC was designed for that. And to prevent
tracking of users and other privacy issues OIDC also specifies pairwise
subject IDs. The plain OAuth 2.x world doesn't have this.

Vladimir

On 08/02/2021 11:07, Warren Parad wrote:
> It doesn't work that way. You suggested to add language to the draft,
> that means the burden of proof is on you to justify adding it.
>
> And I can go stronger, what's the purpose of nho introspection
> endpoint at all, and why encourage sending access tokens to the AS?
>
> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>>     Am 08.02.2021 um 00:56 schrieb Warren Parad <[email-masked]
>>     <mailto:[email-masked]>>:
>>
>>     
>>
>>         I‘m therefore leaning towards explicitly stating in our draft
>>         that it is not intended to be used with refresh tokens.
>>
>>     I'm not following, why explicitly state that it isn't intended.
>>     If an AS wants to provide a similar JSON response to a query with
>>     the refresh token, why not encourage that?
>
>>     Secure your user data and complete your authorization
>>     architecture. Implement Authress
>>     <https://www.google.com/url?q=https://authress.io&source=gmail-imap&ust=1613346997000000&usg=AOvVaw267Z448csTGn3F6REIQ9pT>.
>>
>>
>>     On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt
>>     <torsten=[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hi Andrii,
>>
>>>         Am 07.02.2021 um 21:30 schrieb Andrii Deinega
>>>         <[email-masked] <mailto:[email-masked]>>:
>>>
>>>         
>>>         Hi Torsten,
>>>
>>>         An OAuth client queries the AS to determine the active state
>>>         of an access token and gets the introspection response which
>>>         indicates that this access token is active (using RFC7662).
>>>
>>>         An OAuth client queries the AS to determine the active state
>>>         of a refresh token and gets the introspection response which
>>>         indicates that this refresh token is active (using RFC7662).
>>>
>>>         An OAuth client queries the AS to determine the active state
>>>         of an access token and gets the introspection response (JWT)
>>>         which indicates that this access token is active (using this
>>>         draft).
>>>
>>>         Now, an OAuth client queries the AS to determine the active
>>>         state of a refresh token (using this draft)... How will the
>>>         introspection response look like assuming that the client
>>>         provides the valid refresh token and technically, nothing
>>>         stops it from doing so.
>>
>>         why should the state be provided as JWT?I think the plain
>>         JSON response is sufficient in that case.  I also think using
>>         token introspection for checking the state of a token from
>>         the client side has limited utility. The definitive decision
>>         is always made when the client tries to access a resource. 
>>
>>         I‘m therefore leaning towards explicitly stating in our draft
>>         that it is not intended to be used with refresh tokens.
>>
>>         best regards,
>>         Torsten.
>>
>>>
>>>         Regards,
>>>         Andrii
>>>
>>>
>>>         On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt
>>>         <[email-masked] <mailto:[email-masked]>>
>>>         wrote:
>>>
>>>             Hi Andrii,
>>>
>>>             thanks for your post.
>>>
>>>             The draft is intended to provide AS and RS with a
>>>             solution to exchange signed (and optionally encrypted)
>>>             token introspection responses in order to provide
>>>             stronger assurance among those parties. This is
>>>             important in use cases where the RS acts upon the
>>>             introspection response data and wants the AS to take
>>>             liability re the data quality.
>>>
>>>             I’m not sure whether there are similar use cases if a
>>>             client introspects a refresh token. What is your use case?
>>>
>>>             best regards,
>>>             Torsten. 
>>>
>>>             <mailto:[email-masked]>>:
>>>             >
>>>             > Hi WG,
>>>             >
>>>             > draft-ietf-oauth-jwt-introspection-response-10 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."
>>>             which is true. Although, according to RFC7662, the
>>>             introspection endpoint allows to introspect a refresh
>>>             token as well. Hence, the question I have is how will a
>>>             token introspection response look like when the caller
>>>             provides a refresh token and sets the "Accept" HTTP
>>>             header to "application/token-introspection+jwt"?
>>>             >
>>>             >       • change "If the access token is invalid,
>>>             expired, revoked" by "If a given token is invalid,
>>>             expired, revoked" in section 5 (JWT Response)
>>>             > If not, my suggestion would be to clarify what the AS
>>>             should do when it asked to introspect the refresh token
>>>             in general and additionally, what should happen in the
>>>             same case based on the type of the caller from the AS's
>>>             point of view.
>>>             >
>>>             > Regards,
>>>             > Andrii
>>>             >
>>>
>>         [email-masked] <mailto:[email-masked]>

-- 
Vladimir Dzhuvinov

---

From: Warren Parad <[email-masked]>
Date: Mon, 8 Feb 2021 16:59:47 +0100

None of that justified explicitly stating that refresh token introspection
shouldn't be done. At best it suggests that we should explicitly add
language in the draft to directly encourage it. But if an AS wants to
support it, we shouldn't stop them, or suggest that they can't do it.

Allowing refresh tokens to be introspected can also create a conflict with
> the sec recommendation to rotate them

Not following, can you explain this further?

Warren Parad

Founder, CTO

On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov <[email-masked]>
wrote:

> given OAuth 2.0 already provides a std way to do that - in the access token
> response - the "scope" parameter:
>
> can also create a conflict with the sec recommendation to rotate them. So
> thus it may be a better idea to not let clients assume too much about them.
>
>
> actually has no concept or definition of subject / end-user identifier. And
> this is done for a good reason, because it's not a user authentication
> protocol. OIDC was designed for that. And to prevent tracking of users and
> other privacy issues OIDC also specifies pairwise subject IDs. The plain
> OAuth 2.x world doesn't have this.
>
> Vladimir
>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega <[email-masked]
>>> >:
>>>
>>> 
>>> Hi Torsten,
>>>
>>>> I’m not sure whether there are similar use cases if a client
>>>> introspects a refresh token. What is your use case?
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 9 Feb 2021 13:05:33 +0200

Hi Warren,

On 08/02/2021 17:59, Warren Parad wrote:
> None of that justified explicitly stating that refresh token
> introspection shouldn't be done. At best it suggests that we should
> explicitly add language in the draft to directly encourage it.

Did you mean discourage?

> But if an AS wants to support it, we shouldn't stop them, or suggest
> that they can't do it.

The current draft doesn't mention refresh tokens at all. Its subject is
the introspection of access tokens by authenticated resource servers and
returning the response as a signed JWT. The use of refresh tokens at the
introspection endpoint, per RFC 7662, is not forbidden by the draft.

>
>     Allowing refresh tokens to be introspected can also create a
>     conflict with the sec recommendation to rotate them
>
>

I just double checked the rotation spec. Use that triggers rotation is
clearly specified as "access token response", so there should actually
be no issues with confusing introspection as use.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2

RFC 7662 also seems to imply that a public client with a refresh token
should not normally be able to introspect it, because it can't
authenticate to the AS.

>    To prevent token scanning attacks, the endpoint MUST also require
>    some form of authorization to access this endpoint, such as client
>    authentication as described in OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>] or a separate
>    OAuth 2.0 access token such as the bearer token described in OAuth
>    2.0 Bearer Token Usage [RFC6750 <https://tools.ietf.org/html/rfc6750>].  The methods of managing and
>    validating these authentication credentials are out of scope of this
>    specification.

Vladimir

> On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     At first it may appear that allowing refresh tokens at the
>     introspection endpoint may be a logical thing to do, but in
>     practice there are issues with that and from an OAuth 2.x
>     perspective it's not easy to justify.
>
>     If the point is to let clients check what authorization they have
>     been given OAuth 2.0 already provides a std way to do that - in
>     the access token response - the "scope" parameter:
>
>     If the point is to find if a refresh token is still valid - this
>     can be found out by simply using it. Allowing refresh tokens to be
>     introspected can also create a conflict with the sec
>     recommendation to rotate them. So thus it may be a better idea to
>     not let clients assume too much about them.
>
>     If the AS is going to expose refresh token data to a client it
>     will also have to make a careful judgement what data it exposes.
>
>     For instance "sub". OAuth 2.x in the relation between AS and
>     client actually has no concept or definition of subject / end-user
>     identifier. And this is done for a good reason, because it's not a
>     user authentication protocol. OIDC was designed for that. And to
>     prevent tracking of users and other privacy issues OIDC also
>     specifies pairwise subject IDs. The plain OAuth 2.x world doesn't
>     have this.
>
>     Vladimir
>
>>     It doesn't work that way. You suggested to add language to the
>>     draft, that means the burden of proof is on you to justify adding
>>     it.
>>
>>     Even if you can justify access tokens, there currently isn't
>>     evidence provided why we should explicity discourage.
>>
>>
>>>         Am 08.02.2021 um 00:56 schrieb Warren Parad
>>>         <[email-masked] <mailto:[email-masked]>>:
>>>
>>>         
>>>
>>>             I‘m therefore leaning towards explicitly stating in our
>>>             draft that it is not intended to be used with refresh
>>>             tokens.
>>>
>>>         I'm not following, why explicitly state that it isn't
>>>         intended. If an AS wants to provide a similar JSON response
>>>         to a query with the refresh token, why not encourage that?
>>
>>>>             An OAuth client queries the AS to determine the active
>>>>             state of an access token and gets the introspection
>>>>             response which indicates that this access token is
>>>>             active (using RFC7662).
>>>>
>>>>             An OAuth client queries the AS to determine the active
>>>>             state of a refresh token and gets the introspection
>>>>             response which indicates that this refresh token is
>>>>             active (using RFC7662).
>>>>
>>>>             An OAuth client queries the AS to determine the active
>>>>             state of an access token and gets the introspection
>>>>             response (JWT) which indicates that this access token
>>>>             is active (using this draft).
>>>>
>>>>             Now, an OAuth client queries the AS to determine the
>>>>             active state of a refresh token (using this draft)...
>>>>             How will the introspection response look like assuming
>>>>             that the client provides the valid refresh token and
>>>             why should the state be provided as JWT?I think the
>>>             plain JSON response is sufficient in that case.  I also
>>>             think using token introspection for checking the state
>>>             of a token from the client side has limited utility. The
>>>             definitive decision is always made when the client tries
>>>             to access a resource. 
>>>
>>>             I‘m therefore leaning towards explicitly stating in our
>>>             draft that it is not intended to be used with refresh
>>>             tokens.
>>>
>>>             best regards,
>>>             Torsten.
>>>
>>>>
>>>>             Regards,
>>>>             Andrii
>>>>
>>>>
>>>>                 solution to exchange signed (and optionally
>>>>                 encrypted) token introspection responses in order
>>>>                 to provide stronger assurance among those parties.
>>>>                 This is important in use cases where the RS acts
>>>>                 upon the introspection response data and wants the
>>>>                 I’m not sure whether there are similar use cases if
>>>>                 a client introspects a refresh token. What is your
>>>>                 use case?
>>>>
>>>>                 best regards,
>>>>                 Torsten. 
>>>>
>>>>                 > draft-ietf-oauth-jwt-introspection-response-10
>>>>                 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."
>>>>                 introspection endpoint allows to introspect a
>>>>                 refresh token as well. Hence, the question I have
>>>>                 is how will a token introspection response look
>>>>                 like when the caller provides a refresh token and
>>>>                 sets the "Accept" HTTP header to
>>>>                 >       • replace "a resource server" by "the
>>>>                 caller" in section 4 (Requesting a JWT Response)
>>>>                 > If not, my suggestion would be to clarify what
>>>>                 the AS should do when it asked to introspect the
>>>>                 refresh token in general and additionally, what
>>>>                 should happen in the same case based on the type of
>>>>                 the caller from the AS's point of view.
>>>>                 >
>>>>                 > Regards,
>>>>                 > Andrii
>>>>                 >
>>>>
-- 
Vladimir Dzhuvinov

---

From: Andrii Deinega <[email-masked]>
Date: Thu, 11 Feb 2021 13:47:34 -0800

Hi Vladimir,

What would be a value in the aud claim for refresh tokens?

Regards,
Andrii

On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> language in the draft to directly encourage it.
>
> Did you mean discourage?
>
> But if an AS wants to support it, we shouldn't stop them, or suggest that
> they can't do it.
>
> clearly specified as "access token response", so there should actually be
> no issues with confusing introspection as use.
>
>
> should not normally be able to introspect it, because it can't authenticate
> to the AS.
>
>> And I can go stronger, what's the purpose of nho introspection endpoint
>> at all, and why encourage sending access tokens to the AS?
>>
>>>> I‘m therefore leaning towards explicitly stating in our draft that it
>>>> is not intended to be used with refresh tokens.
>>>
>>>> I‘m therefore leaning towards explicitly stating in our draft that it
>>>> is not intended to be used with refresh tokens.
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
>>>>
>>>> Regards,
>>>> Andrii
>>>>
>>>>
>>>>> > draft-ietf-oauth-jwt-introspection-response-10 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." which
>>>>> is true. Although, according to RFC7662, the introspection endpoint allows
>>>>> to introspect a refresh token as well. Hence, the question I have is how
>>>>> will a token introspection response look like when the caller provides a
>>>>> refresh token and sets the "Accept" HTTP header to

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 15 Feb 2021 13:46:52 +0200

RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud"
value or setting it to the AS, the ultimate consumer, appears valid here.

Vladimir

On 11/02/2021 23:47, Andrii Deinega wrote:
> On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov
>>     introspection shouldn't be done. At best it suggests that we
>>     should explicitly add language in the draft to directly encourage
>>     it.
>
>     Did you mean discourage?
>
>>     But if an AS wants to support it, we shouldn't stop them, or
>>     suggest that they can't do it.
>
>     The current draft doesn't mention refresh tokens at all. Its
>     subject is the introspection of access tokens by authenticated
>     resource servers and returning the response as a signed JWT. The
>     use of refresh tokens at the introspection endpoint, per RFC 7662,
>     is not forbidden by the draft.
>
>
>>
>     I just double checked the rotation spec. Use that triggers
>     rotation is clearly specified as "access token response", so there
>     should actually be no issues with confusing introspection as use.
>
>     RFC 7662 also seems to imply that a public client with a refresh
>     token should not normally be able to introspect it, because it
>     can't authenticate to the AS.
>
>>     architecture. Implement Authress <https://authress.io>.
>>
>>
>>         If the point is to let clients check what authorization they
>>         have been given OAuth 2.0 already provides a std way to do
>>         that - in the access token response - the "scope" parameter:
>>
>>         If the point is to find if a refresh token is still valid -
>>         this can be found out by simply using it. Allowing refresh
>>         tokens to be introspected can also create a conflict with the
>>         sec recommendation to rotate them. So thus it may be a better
>>         idea to not let clients assume too much about them.
>>
>>         If the AS is going to expose refresh token data to a client
>>         it will also have to make a careful judgement what data it
>>         exposes.
>>
>>         client actually has no concept or definition of subject /
>>         end-user identifier. And this is done for a good reason,
>>         because it's not a user authentication protocol. OIDC was
>>         designed for that. And to prevent tracking of users and other
>>         privacy issues OIDC also specifies pairwise subject IDs. The
>>         plain OAuth 2.x world doesn't have this.
>>
>>         Vladimir
>>
>>>         It doesn't work that way. You suggested to add language to
>>>         the draft, that means the burden of proof is on you to
>>>         justify adding it.
>>>
>>>         And I can go stronger, what's the purpose of nho
>>>         introspection endpoint at all, and why encourage sending
>>>         access tokens to the AS?
>>>
>>>>                 I‘m therefore leaning towards explicitly stating in
>>>>                 our draft that it is not intended to be used with
>>>>                 refresh tokens.
>>>>
>>>>             intended. If an AS wants to provide a similar JSON
>>>>             response to a query with the refresh token, why not
>>>>             encourage that?
>>>
>>>>>                 An OAuth client queries the AS to determine the
>>>>>                 active state of an access token and gets the
>>>>>                 introspection response which indicates that this
>>>>>                 An OAuth client queries the AS to determine the
>>>>>                 active state of a refresh token and gets the
>>>>>                 introspection response which indicates that this
>>>>>                 An OAuth client queries the AS to determine the
>>>>>                 active state of an access token and gets the
>>>>>                 introspection response (JWT) which indicates that
>>>>>                 this access token is active (using this draft).
>>>>>
>>>>>                 Now, an OAuth client queries the AS to determine
>>>>>                 the active state of a refresh token (using this
>>>>>                 draft)... How will the introspection response look
>>>>>                 like assuming that the client provides the valid
>>>>>                 refresh token and technically, nothing stops it
>>>>>                 from doing so.
>>>>
>>>>                 plain JSON response is sufficient in that case.  I
>>>>                 also think using token introspection for checking
>>>>                 the state of a token from the client side has
>>>>                 limited utility. The definitive decision is always
>>>>                 made when the client tries to access a resource. 
>>>>
>>>>                 I‘m therefore leaning towards explicitly stating in
>>>>                 our draft that it is not intended to be used with
>>>>                 refresh tokens.
>>>>
>>>>                 best regards,
>>>>                 Torsten.
>>>>
>>>>>
>>>>>                 Regards,
>>>>>                 Andrii
>>>>>
>>>>>
>>>>>                     The draft is intended to provide AS and RS
>>>>>                     with a solution to exchange signed (and
>>>>>                     optionally encrypted) token introspection
>>>>>                     responses in order to provide stronger
>>>>>                     assurance among those parties. This is
>>>>>                     important in use cases where the RS acts upon
>>>>>                     the introspection response data and wants the
>>>>>                     I’m not sure whether there are similar use
>>>>>                     cases if a client introspects a refresh token.
>>>>>                     What is your use case?
>>>>>
>>>>>                     best regards,
>>>>>                     Torsten. 
>>>>>
>>>>>                     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." which is true. Although,
>>>>>                     according to RFC7662, the introspection
>>>>>                     endpoint allows to introspect a refresh token
>>>>>                     as well. Hence, the question I have is how
>>>>>                     will a token introspection response look like
>>>>>                     when the caller provides a refresh token and
>>>>>                     >       • change "If the access token is
>>>>>                     invalid, expired, revoked" by "If a given
>>>>>                     token is invalid, expired, revoked" in section
>>>>>                     5 (JWT Response)
>>>>>                     > If not, my suggestion would be to clarify
>>>>>                     what the AS should do when it asked to
>>>>>                     introspect the refresh token in general and
>>>>>                     additionally, what should happen in the same
>>>>>                     case based on the type of the caller from the
>>>>>                     AS's point of view.
>>>>>                     >
>>>>>                     > Regards,
>>>>>                     > Andrii
>>>>>                     >
>>>>>
-- 
Vladimir Dzhuvinov