Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502AF3A09A6 for ; Wed, 4 Mar 2020 13:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YevgZOXqofB for ; Wed, 4 Mar 2020 13:44:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DE23A099F for ; Wed, 4 Mar 2020 13:44:37 -0800 (PST) Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 024LfdJG007060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Mar 2020 16:42:35 -0500 From: Justin Richer Message-Id: <7C1D0E68-5D7B-4C0A-AE13-D513AB8723DE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_417DAE99-32AC-4F0D-808D-0F7445877B49" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 4 Mar 2020 16:42:34 -0500 In-Reply-To: Cc: David Waite , oauth@ietf.org To: Bill Jung References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 21:44:40 -0000 --Apple-Mail=_417DAE99-32AC-4F0D-808D-0F7445877B49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Why would the client need to know the refresh token=E2=80=99s expiry? = Can=E2=80=99t they just use the refresh token and see? Either way it=E2=80= =99s a single round trip to the AS and the client gets the same answer = with the same recovery code path. =E2=80=94 Justin > On Mar 4, 2020, at 2:01 PM, Bill Jung = wrote: >=20 > 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?=20 >=20 > Surely some clarification will eliminate the time spent on unnecessary = discussion among developers.=20 >=20 > =09 > Bill Jung=09 > Manager, Response Engineering=09 > bjung@pingidentity.com =09 > w: +1 604.697.7037=09 > Connect with us: = = = = = = = = >=20 > On Sun, Mar 1, 2020 at 9:33 PM David Waite = > wrote: > On Mar 1, 2020, at 10:11 PM, Andrii Deinega > wrote: > >=20 > > 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)? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -DW >=20 > >=20 > > Regards, > > Andrii > >=20 > > On Sun, Mar 1, 2020 at 7:38 PM David Waite = > = wrote: > >>=20 > >> 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. > >>=20 > >> -DW > >>=20 > >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega = > wrote: > >>>=20 > >>> Hello Bill, > >>>=20 > >>> 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. > >>>=20 > >>> 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. > >>>=20 > >>> -- > >>> Regards, > >>> Andrii > >>>=20 > >>>=20 > >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > >>> > wrote: > >>>>=20 > >>>> Hello, hopefully I am using the right email address. > >>>>=20 > >>>> 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?" > >>>>=20 > >>>> 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) > >>>>=20 > >>>> 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. > >>>>=20 > >>>> Thanks in advance. > >>>>=20 > >>>>
> >>>> 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". > >>>>=20 > >>>> 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.. > >>>>=20 > >>>>=20 > >>>> Bill Jung > >>>> Manager, Response Engineering > >>>> bjung@pingidentity.com > >>>> w: +1 604.697.7037 > >>>> Connect with us: > >>>>=20 > >>>> 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 > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth = > >>>=20 > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf..org > >>> https://www.ietf.org/mailman/listinfo/oauth = > >>=20 >=20 >=20 > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_417DAE99-32AC-4F0D-808D-0F7445877B49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Why = would the client need to know the refresh token=E2=80=99s expiry? = Can=E2=80=99t they just use the refresh token and see? Either way it=E2=80= =99s a single round trip to the AS and the client gets the same answer = with the same recovery code path.

 =E2=80=94 Justin

On Mar = 4, 2020, at 2:01 PM, Bill Jung <bjung=3D40pingidentity.com@dmarc.ietf.org> = 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. 

3D"Ping
Bill = Jung
Manager, = Response Engineering
bjung@pingidentity.com
w: +1 604.697.7037
Connect with = us:3D"Glassdoor 3D"LinkedIn  3D"twitter 3D"facebook 3D"youtube  3D"Blog


On Sun, Mar 1, 2020 at 9:33 PM David Waite = <david=3D40alkaline-solutions.com@dmarc.ietf.org> wrote:
On Mar 1, = 2020, at 10:11 PM, Andrii Deinega <andrii.deinega@gmail.com> wrote:
> 
> 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)?

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
> 
> On Sun, = Mar 1, 2020 at 7:38 PM David Waite <david@alkaline-solutions.com> wrote:
>> 
>> 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 <andrii.deinega@gmail.com> 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=3D40pingidentity.com@dmarc.ietf.org> = 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
>>>> bjung@pingidentity.com
>>>> 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
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> = _______________________________________________
>>>= OAuth mailing list
>>> OAuth@ietf..org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 


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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_417DAE99-32AC-4F0D-808D-0F7445877B49--