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 79A333A0A04 for ; Wed, 4 Mar 2020 14:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com 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 0dg3ca82AJuh for ; Wed, 4 Mar 2020 14:06:29 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A343A093A for ; Wed, 4 Mar 2020 14:06:29 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id y17so2817068lfe.8 for ; Wed, 04 Mar 2020 14:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nnmZOVU0ALvSmEPjXih7uuNDQtSMDJ2s+EnSHF7FsrM=; b=UuYy0lUTvOJD4yiM5Jsxx5UDp5W5PWO81QlD/yFrQW311kALVDI/hi5W16ANRsSrYK YQ9lRSMLJ2Hq5d+EIpVSeOrz8N0ERxcyfRbQQZkE1qAMWq1KXPNIuAtRx4cItSIcDvHS 6JNDNjTRyF6rNv/EqmwWycrmhMcpSYqE1en6wnaZqo+U2iElWAsNAkjg89dvfQHTipDV LloRS0rDOnV30gn+6MMwkTUDoiXfovVzpBH2RqI2Y+3x+DCVNSdn00GMl35x2eDKo8y7 Q2ZyJxP89ETU58U13o5tfXUZrdklRjyztvioe34adcjLqY6AVhROa1233QBOemBd1ayB V4jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nnmZOVU0ALvSmEPjXih7uuNDQtSMDJ2s+EnSHF7FsrM=; b=dSu28rgl6K/f5A+ZLUZr9zoo7sj/wOGGh971XY8c1SP+kmafFLo3vBOH5iOZffHeHa yxeDX7pfjcY/yG47pVbGTjal/4xoz2tZ0owNnEDLcMQxBeKygFA7AYH//D6rIx4O4QFO aZeue+1lfcAlOCGA3nK4XsCBe1jbnfhX75W6PioXIBPFq2QmNB02Gu/iybyy/0rfZpCB 8acbOb+7l31OyoaB29rkbWJKChZss19Taz/BpvkPcFhe0pGah0FjaJ9kFnWgmhWiUMTj PQ9j6dIrLNiq4HFQNWfUzwlHT7zMz2k63oZuWhNxbRE9BS0AdL4Wu9lu4ryhhykR9URT 2ydQ== X-Gm-Message-State: ANhLgQ3+vy438qRrIWVnaBo40lkQ+2XJcvDefmbF5qs6genGJEl+0CYF mOeMI/ZaxLnm8Oj3eJBQp47T1Extn9O/c89aTMPw9ga3NH2EV0jgGHq+itkvGMm9g/LkD5GjWV7 n0Sncwsnk1VgiRQ== X-Google-Smtp-Source: =?utf-8?q?ADFU+vvxj6w2Z+ir26uCT7w7ka+MncflAZ9bAxjH0UhM?= =?utf-8?q?387MDwU8IV7F8nWW7asPo4D0LKH4joiBpplyqrgM4+YFOqQ=3D?= X-Received: by 2002:a19:5f1c:: with SMTP id t28mr2792753lfb.131.1583359587400; Wed, 04 Mar 2020 14:06:27 -0800 (PST) MIME-Version: 1.0 References: <7C1D0E68-5D7B-4C0A-AE13-D513AB8723DE@mit.edu> In-Reply-To: <7C1D0E68-5D7B-4C0A-AE13-D513AB8723DE@mit.edu> From: Bill Jung Date: Wed, 4 Mar 2020 14:06:14 -0800 Message-ID: To: Justin Richer Cc: David Waite , oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c257c905a00ea111" 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 22:06:33 -0000 --000000000000c257c905a00ea111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yep, I agree. But that's just me agreeing with it. Unless the spec clearly says it everybody will throw different ideas and use cases. That's why I want the spec to clarify this. On Wed, Mar 4, 2020, 1:42 PM Justin Richer, wrote: > 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 roun= d trip to > the AS and the client gets the same answer with the same recovery code pa= th. > > =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, the= n > 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 rig= ht > thing to do even? > > Surely some clarification will eliminate the time spent on unnecessary > discussion among developers. > > [image: Ping Identity] > > Bill Jung > Manager, Response Engineering > bjung@pingidentity.com > w: +1 604.697.7037 > Connect with us: [image: Glassdoor logo] > [image: > LinkedIn logo] [image: twitter > logo] [image: facebook logo] > [image: youtube logo] > [image: Blog logo] > > > > > > > On Sun, Mar 1, 2020 at 9:33 PM David Waite 40alkaline-solutions.com@dmarc.ietf.org> wrote: > >> On Mar 1, 2020, at 10:11 PM, Andrii Deinega >> 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 resourc= e >> 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 sti= ll >> 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 me= an >> that access tokens used to authorize the call to the introspection endpo= int >> must be issued to a confidential client - public clients cannot protect >> credentials to perform an authentication. You want to limit introspectio= n >> to prevent denial of service and probing attacks, and to limit the amoun= t >> 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 signali= ng >> back to the resource. >> >> >> >> -DW >> >> >> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega >> 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 a= n >> >>> 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 chec= k >> >>> (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 >> >>> 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 cli= ent >> 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 t= hem. >> >>>> However, the spec also mentions that refresh tokens can also be use= d >> 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 tok= en. >> (Cannot imagine how/why a resource server would introspect a refresh tok= en) >> >>>> >> >>>> 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 th= e >> RFC should clearly mention it. >> >>>> >> >>>> Thanks in advance. >> >>>> >> >>>>
>> >>>> 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 f= ile >> 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000c257c905a00ea111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yep, I agree. But that's just me agreeing with it. Un= less the spec clearly says it everybody will throw different ideas and use = cases. That's why I want the spec to clarify this.

On Wed, Mar 4, 2020,= 1:42 PM Justin Richer, <jricher@mit.= edu> wrote:
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.
=C2=A0=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 app= s) asked that AS allow introspection=C2=A0endpoint to RPs so that RPs can c= heck their refresh token's=C2=A0expiry. If AS allows this, which the sp= ec 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. Bu= t then is that the right thing to do even?=C2=A0

Surely = some clarification=C2=A0will eliminate the time spent on unnecessary discus= sion among developers.=C2=A0

3D"Ping
Bill Jung =
Manager, Response= Engineering
bjung@pingid= entity.com
w: +1 604.697.7037
Connect with us:3D"Glassdoor<= /a> 3D"LinkedIn=C2=A0 3D"twitter 3D"facebook 3D"youtube=C2=A0 3D"Blog

<= /div>

On Sun, Mar 1, 2020 at 9:3= 3 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:<= br>>=C2=A0
> How would the authorization server know = who actually uses the
> introspection endpoint assuming that a protec= ted resource and a client
> application use the same credentials (cli= ent_id and client_secret)?

In the external context, you have a clien= t accessing a protected resource with an access token. The client should tr= eat 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. How= ever, the client logic still should never be introspecting the tokens.
<= br>The security considerations also say that you must prove the authenticat= ion of the protected resource, which I have interpreted to mean that access= tokens used to authorize the call to the introspection endpoint must be is= sued to a confidential client - public clients cannot protect credentials t= o perform an authentication. You want to limit introspection to prevent den= ial of service and probing attacks, and to limit the amount of information = on viable attacks conveyed if someone steals a token.

-DW

>= ;=C2=A0
> Regards,
> Andrii
>=C2=A0
> On Sun, Mar 1, 2020 at 7:38 PM David Waite <david= @alkaline-solutions.com> wrote:
>>=C2=A0
&g= t;> 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.
>>=C2=A0
>> -DW
>= ;>=C2=A0
>>> On Mar 1, 2020, at 12:12 AM, Andri= i Deinega <andrii.deinega@gmail.com> wrote:
>>>= =C2=A0
>>> Hello Bill,
>>>=C2=A0=
>>> I'm just thinking out loud about possible scena= rios for a protected
>>> resource here... It may decide to revo= ke a refresh token if a client
>>> application tried to use it = instead of an access token when the
>>> protected resource is p= aranoid about security. In order to do that an
>>> introspectio= n response should include a non-standard parameter which
>>> in= dicates that the requested token is refresh_token.
>>>=C2= =A0
>>> A user of the introspection endpoint should rely= only on a value of
>>> the active parameter (which is a boolea= n indicator) of the endpoint
>>> response. This applies to both= types of tokens. Note, the expiration
>>> date, as well as oth= er parameters, are defined as optional in the
>>> specification= . Both token types can be revoked before the expiration
>>> dat= e comes even if this parameter is presented as part of the
>>> = response. In my opinion, there are a number of reasons why this check
&g= t;>> (for a refresh token) can be useful on the client application si= de.
>>>=C2=A0
>>> --
>>> R= egards,
>>> Andrii
>>>=C2=A0
>&g= t;>=C2=A0
>>> On Fri, Feb 28, 2020 at 1:59 AM B= ill Jung
>>> <bjung=3D40pingidentity.com@dmar= c.ietf.org> wrote:
>>>>=C2=A0
>>= ;>> Hello, hopefully I am using the right email address.
>>&= gt;>=C2=A0
>>>> Simply put, can this spec be= enhanced to clarify "Who can use the introspection endpoint for a ref= resh token? A resource provider or a client app or both?"
>>&= gt;>=C2=A0
>>>> RFC7662 clearly mentions tha= t 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&#= 39;ll give unnecessary token information to them.
>>>> Howev= er, the spec also mentions that refresh tokens can also be used against the= endpoint.
>>>> In case of refresh tokens, user of the endpo= int should be a client app because refresh tokens are used by clients to ge= t another access token. (Cannot imagine how/why a resource server would int= rospect a refresh token)
>>>>=C2=A0
>>= >> Is it correct to assume that the endpoint should be allowed to cli= ent apps if they want to examine refresh token's expiry time? Then the = RFC should clearly mention it.
>>>>=C2=A0
&g= t;>>> Thanks in advance.
>>>>=C2=A0>>>> <Details from the spec>
>>>> In=C2=A0https://tools.ietf.org/html/rfc7662<= br>>>>> In '1.=C2=A0 Introduction' section says,
>= ;>>> "This specification defines a protocol that allows autho= rized
>>>> protected resources to query the authorization se= rver to determine
>>>> the set of metadata for a given token= that was presented to them by
>>>> an OAuth 2.0 client.&quo= t;
>>>> Above makes clear that user of the endpoint is a &qu= ot;protected resource".
>>>>=C2=A0
>= >>> And under 'token' in '2.1.=C2=A0 Introspection Req= uest' section says,
>>>> "For refresh tokens,
&g= t;>>> this is the "refresh_token" value returned from th= e token endpoint
>>>> as defined in OAuth 2.0 [RFC6749], Sec= tion 5.1."
>>>> So looks like a refresh token is allowe= d for this endpoint..
>>>>=C2=A0
>>>= ;>=C2=A0
>>>> Bill Jung
>>>> = Manager, Response Engineering
>>>>=C2=A0bju= ng@pingidentity.com
>>>> w: +1 604.697.7037
>>&= gt;> Connect with us:
>>>>=C2=A0
>>= >> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited...=C2=A0= 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
>>>>=C2=A0OAu= th@ietf.org
>>>>=C2=A0https://www.ietf.org/mailman/listinfo/oauth
>>>=C2=A0
>>> ___________________________________________= ____
>>> OAuth mailing list
>>>=C2=A0<= a href=3D"mailto:OAuth@ietf.org" target=3D"_blank" rel=3D"noreferrer">OAuth= @ietf..org
>>>=C2=A0https://www.ietf.org/mailman/listinfo/oauth
>>=C2=A0<= /span>


CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.___________________= ____________________________
OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000c257c905a00ea111--