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

Justin Richer <jricher@mit.edu> Wed, 04 March 2020 21:44 UTC

Return-Path: <jricher@mit.edu>
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 <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; 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 <jricher@mit.edu>
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, 04 Mar 2020 16:42:34 -0500
In-Reply-To: <CAErhd0PkNzFTVgjSS24RzjKZ+sq2Hubhr3j_hmnbtgLuQgOGhQ@mail.gmail.com>
Cc: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, oauth@ietf.org
To: Bill Jung <bjung=40pingidentity.com@dmarc.ietf.org>
References: <CAErhd0OLTMKxXnT-_X6DyWYUxe==gTXdcHKLjOEDTmXCUZNxrg@mail.gmail.com> <CALkShcuLTd02iu309dCZ8PtnzbKd5b9PsVS_DWUMGWXgFovwMg@mail.gmail.com> <C0C40A3E-2455-4C86-B504-AB18F31975D9@alkaline-solutions.com> <CALkShct=sYSq-HoG=yMiV2BqT8+F=gnej+p2GgFD87FV1OQu3w@mail.gmail.com> <D3D1BFB8-CE54-4E48-A8B9-45E01ED2B637@alkaline-solutions.com> <CAErhd0PkNzFTVgjSS24RzjKZ+sq2Hubhr3j_hmnbtgLuQgOGhQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DP94UcRt5tf2T6hIszMx-TmI5Jc>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 21:44:40 -0000

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=40pingidentity.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. 
> 
>  <https://www.pingidentity..com/> <https://www.pingidentity.com/>	
> Bill Jung	
> Manager, Response Engineering	
> bjung@pingidentity.com <mailto:bjung@pingidentity.com>	
> 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=40alkaline-solutions.com@dmarc.ietf.org <mailto:40alkaline-solutions.com@dmarc.ietf.org>> wrote:
> On Mar 1, 2020, at 10:11 PM, Andrii Deinega <andrii.deinega@gmail.com <mailto: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 <mailto: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 <mailto: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=40pingidentity.com@dmarc.ietf.org <mailto:40pingidentity.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 <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 <mailto: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 <mailto:OAuth@ietf.org>
> >>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >>> 
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf..org <mailto:OAuth@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/oauth <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 <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>