[OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?
Bill Jung <bjung@pingidentity.com> Fri, 28 February 2020 06:21 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 28C713A1104 for <oauth@ietfa.amsl.com>; Thu, 27 Feb 2020 22:21:10 -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 2sAmEcBv4z31 for <oauth@ietfa.amsl.com>; Thu, 27 Feb 2020 22:21:07 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 014F53A1103 for <oauth@ietf.org>; Thu, 27 Feb 2020 22:21:05 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id v6so1208227lfo.13 for <oauth@ietf.org>; Thu, 27 Feb 2020 22:21:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=RC6NEDKQqmAmnCWDq7X9AuB+dwS8kqgM7gU7Rh4AnFY=; b=CYAyemCLrLNZTbLj/mFvry9rsolPNMXxa0MIY2cehQHCiMNc44OuKLuXjptwrq+b9Z xMBmsrR/1NfA9UELbngX/RtinRiEj5dxkpf5uh9xVnjleZBD5O0eW8pYTl2vsrpdcgvC R1u/eYJwGkUvIYnQjDhiJSz4YHkkhY9RqgKLEi+e9rj/O7UzjnURPI4kvntTLuM+Iv4f WLE8/PaljA1tPZfDF6saB+7VTrNSPJda7uODiXZK0xRx3eVSl91hU25PohLbCqUDNGxC ub1Vp4k1lkIqdcC9P8trJQ6tM4pzS8DgFvbNXT14I7wSl/0kxklIXQI4xZaM90qcaTd2 HJHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RC6NEDKQqmAmnCWDq7X9AuB+dwS8kqgM7gU7Rh4AnFY=; b=D3VzgIp/8hOj0LOuHcT1J8rtvMBqbxy5SLr5FS7Xf1rQjJGUAjLmWstbh6uc855ORb iLLSelJkLS2e7We0TA/CjeGRJqOTdIjn1HLfP2jVsnmUUDqtOgUD9oWrzUOK5sKyCzgO ub7DTP0p4NdkgMe50/IcJMv5B6rztXEMDvyjWKbQifCaoVoxSM5xAJeaML1g/41OIG4R 003PgaX8chjWUWqeL1NNQMB2isdGpYtyhEh+NjoLhIjs3AHtn5Riu6WF1n6HZHw9Copk clsXUBKq8nMBrwlNORoGs7bZhoAIm/EeMTCwtVG5Gf22DeFfHBoEyGufLktyp+1WQzDx xQKQ==
X-Gm-Message-State: ANhLgQ1zFNSCm7YRcQ6mN1lM/0QSQhkgsaLojnSPI8iGYblivI5jafB0 iLj8kihdF+J87vPcpYG6PJDVk1lE9gyw3T38UB3sqtAvQTZv/ocdTqTaFXK7AurXcF0btGwN4Zh XXdYKhtzQqFm67hm41+E=
X-Google-Smtp-Source: ADFU+vu+awKRKZYadcnJyF4neruPaDU9cN1WHHwFAHRWkJMJjcfy7idVaoKCdg03yZ5G8XWHwvncJXzOkkHmK5ZKVBk=
X-Received: by 2002:a19:915c:: with SMTP id y28mr1709227lfj.127.1582870863344; Thu, 27 Feb 2020 22:21:03 -0800 (PST)
MIME-Version: 1.0
From: Bill Jung <bjung@pingidentity.com>
Date: Thu, 27 Feb 2020 22:20:52 -0800
Message-ID: <CAErhd0OLTMKxXnT-_X6DyWYUxe==gTXdcHKLjOEDTmXCUZNxrg@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000890bcb059f9cd700"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pJD5n5GW6Qmk-BXtGddx7uBEE8k>
X-Mailman-Approved-At: Fri, 28 Feb 2020 01:59:43 -0800
Subject: [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: Fri, 28 Feb 2020 06:27:26 -0000
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 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-WG] OAuth 2.0 Token Introspection in RFC76… Bill Jung
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… David Skaife
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Andrii Deinega
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Andrii Deinega
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… David Waite
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Andrii Deinega
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… David Waite
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Bill Jung
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Bill Jung
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Bill Jung
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Andrii Deinega
- Re: [OAUTH-WG] OAuth 2.0 Token Introspection in R… Torsten Lodderstedt