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

[Vladimir Dzhuvinov <[e-mail]>]

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:
> 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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>>
>>>         wrote:
>>>
>>>
>>>
>>>>             Am 08.02.2021 um 00:56 schrieb Warren Parad
>>>>             <[e-mail] <mailto:[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]
>>>>             <mailto:[e-mail]>> wrote:
>>>>
>>>>                 Hi Andrii,
>>>>
>>>>>                 Am 07.02.2021 um 21:30 schrieb Andrii Deinega
>>>>>                 <[e-mail]
>>>>>                 <mailto:[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]
>>>>>                 <mailto:[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]
>>>>>                     <mailto:[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] <mailto:[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 list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>         -- 
>>         Vladimir Dzhuvinov
>>
>     -- 
>     Vladimir Dzhuvinov
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Vladimir Dzhuvinov