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

[Andrii Deinega <[e-mail]>]

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 <[e-mail]>
wrote:

> 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
>
>
> Not following, can you explain this further?
>
> 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.
>
> https://tools.ietf.org/html/rfc7662#section-2.2
>
>    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
>
>
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://authress.io>.
>
>
> On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov <[e-mail]>
> 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:
>>
>> 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.
>>
>> 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 <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> Am 08.02.2021 um 00:56 schrieb Warren Parad <[e-mail]>:
>>>
>>> 
>>>
>>>> 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?
>>>
>>>
>>> Why should we encourage it?
>>>
>>>
>>> Warren Parad
>>>
>>> Founder, CTO
>>> 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=
>>> [e-mail]> wrote:
>>>
>>>> Hi Andrii,
>>>>
>>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega <[e-mail]
>>>> >:
>>>>
>>>> 
>>>> 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.
>>>>
>>>>
>>>> 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 <
>>>> [e-mail]> 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.
>>>>>
>>>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega <
>>>>> [e-mail]>:
>>>>> >
>>>>> > 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
>>>>> >       • 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
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613346997000000&usg=AOvVaw3ZHWt08dlcHAgxyfj2hrsX>
>>>>
>>>
>> _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>> --
>> Vladimir Dzhuvinov
>>
>> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>