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

Bill Jung <bjung@pingidentity.com> Wed, 04 March 2020 18:46 UTC

Return-Path: <bjung@pingidentity.com>
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 59A103A1493 for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2020 10:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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_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 jkS65gl9RKRm for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2020 10:45:57 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 5035A3A1491 for <oauth@ietf.org>; Wed, 4 Mar 2020 10:45:57 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id z9so2399204lfa.2 for <oauth@ietf.org>; Wed, 04 Mar 2020 10:45:57 -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=FzrUZ08nFTWKDPnRbiQFSzP8agfVzzXvMkO/ZZaDoPM=; b=MHNIgnMfiHazhKJaKBCNiroyMfck1oyp0XY9aXWGIBS6kA222hpISRdtv6d0FBJoWd 2TOH2hTgII+j39tHkHz06tNBnJ8jD6U9HEVFosBAkefEc/5ZcdqWP/PfEaJX2D51aVRS r3AT0GTztMMojrjIwkuCu4FiyRmNqNGpuk94dOmYCzwIBK6FcmJ4wnrBeV7JfTJi40pD m0QLtbbxAdYmQk7wGi9sunb2mC6renRDsn7U+ujlSTwNoTC/j3hr5B1rlD1iBcqxIHLS htgPIgCU2+5xKOVc2XqH368ODx6NCInAQVpl6Mfnl3vPXTg7C8kTY+afeAm6snYLGlx0 m/Uw==
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=FzrUZ08nFTWKDPnRbiQFSzP8agfVzzXvMkO/ZZaDoPM=; b=KlqH1Jh30EG3qwEl0gomihsD2J5HzLhQn6K5Omb6J8/vEhCR0ayrZlQFG0XiazJybL aJxgza6Ov63CSIv2FuOW2OYqztQwY0t8Hi4vWI9FW3GoP9kZeCAZrAJPlJxYGTrj+btx DHQ43FDS1463QVLYOk5GkpfEmUgePvE1TMs8ahK+LLnASm+4jj57SzA6scZnpKSWZSij k2/jb/K/kNNsDmTU6asJCVpZ5QzSOZ2qk1d9yKaQnDVd99kzflxWTWnSLPA4+RRDXWE3 vJns58D4Bv0yc4qj5h4R6XAH7EV7sLyQNoVKTkYrlZNC8YVJzjaOo/10SNlGw/QkOBBc +9ig==
X-Gm-Message-State: ANhLgQ3MZw8B/AHVck1vrk97WHmnPIE8Wt5YfcbXLbE+5ndnun8lyZqM RBKEjTYQduWZyM1F7V5mzu6o9sF7j/c4daQbsb4s0BQQDvyG+SY7YVEIdenfGTGWEEgjx3gsi2+ iAOTX0lHecOSUBw==
X-Google-Smtp-Source: ADFU+vsEy6Hj9eACjH0fQY7LfOlzpbD/9LFjkzzqewnOqWdqV/AdDhrW9383wOCMb4CtegE4zXknPchEZjL7TWsO5Yg=
X-Received: by 2002:a19:c184:: with SMTP id r126mr2932467lff.40.1583347554559; Wed, 04 Mar 2020 10:45:54 -0800 (PST)
MIME-Version: 1.0
References: <CAErhd0OLTMKxXnT-_X6DyWYUxe==gTXdcHKLjOEDTmXCUZNxrg@mail.gmail.com> <CAKiOsZvn1Kdr4QC_d=drToqOZ39TKcwb-u8P8PoOKnsv03pNRA@mail.gmail.com>
In-Reply-To: <CAKiOsZvn1Kdr4QC_d=drToqOZ39TKcwb-u8P8PoOKnsv03pNRA@mail.gmail.com>
From: Bill Jung <bjung@pingidentity.com>
Date: Wed, 04 Mar 2020 10:45:43 -0800
Message-ID: <CAErhd0OjE62WY5=x6FTkVm42vxDqjf353AFC9DUW5xwNaK8x4w@mail.gmail.com>
To: David Skaife <blue.ringed.octopus.guy@gmail.com>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008bc63b05a00bd4d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QOlG0Wpd7p9VP_i0Hptfx6JbS4o>
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 18:46:04 -0000

Yes, actually the term "protected resource" is awkward. It is the resource
server's jog to introspect tokens to protect those protected resources.

<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Bill Jung
Manager, Response Engineering
bjung@pingidentity.com
w: +1 604.697.7037
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
<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 Fri, Feb 28, 2020 at 6:55 AM David Skaife <
blue.ringed.octopus.guy@gmail.com> wrote:

> Hi,
>
> In additional to Bill's query, the use of the term "protected resource" in
> the context of RFC7662 is quite confusing. As defined by RFC6749 (which
> RFC7662 defers to for definition of the terms), the term "protected
> resource" is defined as an "access-restricted resource" that a client can
> request.. In the context of RFC7662, it doesn't make sense for an
> "access-restricted resource" to be making any requests to the introspection
> endpoints - surely it is the resource server that is the intended consumer
> of the introspection endpoints? This is also backed up by Section 4
> (Security Considerations) of RFC7662 which reverts to using the term
> "resource server" as the consumer of the introspection endpoints.
> For example, in these quotes:
> "However, since resource servers using token introspection rely on the authorization
> server to determine the state of a token.." and
> "...the authorization server MUST determine whether or not the token can be
> used at the resource server making the introspection call"
>
> Apologies if I've misinterpreted something here, but if RFC7662 has a
> different meaning for the term "protected resource" from RFC6749 then it
> should be stated clearly within that document. I also agree with Bill's
> observation that it doesn't make sense for a refresh token to passed into
> an introspection request as a refresh token should only be accessible to
> the client and the authorization server (neither of which are intended
> consumers of the introspection endpoints).
>
>
> Many thanks,
> David Skaife
>
> On Fri, Feb 28, 2020 at 9:59 AM Bill Jung <bjung=
> 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 authorizedprotected
>> resources to query the authorization server to determinethe set of metadata
>> for a given token that was presented to them byan 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 endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."*
>> So looks like a refresh token is allowed for this endpoint.
>>
>>
>> <https://www.pingidentity.com>[image: Ping Identity]
>> <https://www.pingidentity.com>
>> Bill Jung
>> Manager, Response Engineering
>> bjung@pingidentity.com
>> w: +1 604.697.7037
>> Connect with us: [image: Glassdoor logo]
>> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
>> LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
>> logo] <https://twitter.com/pingidentity> [image: facebook logo]
>> <https://www.facebook.com/pingidentitypage> [image: youtube logo]
>> <https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
>> <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>
>>
>> *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
>>
>

-- 
_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._