Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens
Vladimir Dzhuvinov <vladimir@connect2id.com> Mon, 08 February 2021 15:13 UTC
Return-Path: <vladimir@connect2id.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 08AC43A0E32 for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2021 07:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.807
X-Spam-Level:
X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=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 EYhDxIvP7AGe for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2021 07:13:34 -0800 (PST)
Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (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 3C7473A0E30 for <oauth@ietf.org>; Mon, 8 Feb 2021 07:13:34 -0800 (PST)
Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 98EFlmztU06jR98EGlp7vL; Mon, 08 Feb 2021 08:13:33 -0700
x-spam-cmae: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=6021551d p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=PzzBoh6yAAAA:8 a=pGLkceISAAAA:8 a=F18cNVTIXlhlJkRzNvQA:9 a=QEXdDO2ut3YA:10 a=1xOB4YiTHOsA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=W-gxJ9TLX_f0q5FysN4A:9 a=A58rr3yYCnV2Q1aA:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 a=L62bugPwxnpkHHKveAwe:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
X-CMAE-Analysis: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=6021551d p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=PzzBoh6yAAAA:8 a=pGLkceISAAAA:8 a=F18cNVTIXlhlJkRzNvQA:9 a=QEXdDO2ut3YA:10 a=1xOB4YiTHOsA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=W-gxJ9TLX_f0q5FysN4A:9 a=A58rr3yYCnV2Q1aA:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 a=L62bugPwxnpkHHKveAwe:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>, torsten@lodderstedt.net
Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, oauth <oauth@ietf.org>
References: <CAJot-L05Nb5FQQ_OOgW_s4Mswo0GW3-j7HTTxtbR2OgqESijWg@mail.gmail.com> <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> <CAJot-L1tMjM=JHtn3sHROLtzoxAkOGr33m66mcRH9-Vvss6QRg@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com>
Date: Mon, 08 Feb 2021 17:13:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAJot-L1tMjM=JHtn3sHROLtzoxAkOGr33m66mcRH9-Vvss6QRg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070309020105040506060909"
X-CMAE-Envelope: MS4xfKdKA9CWRJktmSUyCCykJh8mhgzK9teGxW8g/Z5ndmmMmvLhMk3ZVVyXB11rAvXbdsAujgwhM0v6hOziHSKwd5ZpchQktrNfK0E/OaSlLpf2vr2GqD9S kK1jyIDvA+SZB85V8vW+x344vreiF39Atbzpgl5l7PcLlt0aFyNb6B4qJcVeX47oRLepJ/7Al1BGnEzINbPwO3nUjOZJtdybQBQrmInVhT/IKZHniSOkwVna XeYIjjBq6fYUJ4BVpVO3QA+PJ4Kz42b6XTBXgKeDJRzBUbgKmTyY4/KPA2UC+cBj7KvT8RUSgohrgT/G+zFyfBLawt4XPn/zl5TWCrQ7gcPziFbV+Xd9YO7R v6e7yKOmRVJgPobpK1bQzUyCdYVcSYhXZFxn5yweHj2Mg4P8ezQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Df-aVIl344uCMB7isedsUBOLgqE>
Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens
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: Mon, 08 Feb 2021 15:13:37 -0000
At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify. If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope" parameter: https://tools.ietf.org/html/rfc6749#section-5.1 RAR has a similar parameter: https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1 If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2 If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes. https://tools.ietf.org/html/rfc7662#section-2.2 For instance "sub". OAuth 2.x in the relation between AS and client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this. Vladimir On 08/02/2021 11:07, Warren Parad wrote: > It doesn't work that way. You suggested to add language to the draft, > that means the burden of proof is on you to justify adding it. > > Otherwise I could just say why not? > > And I can go stronger, what's the purpose of nho introspection > endpoint at all, and why encourage sending access tokens to the AS? > > Even if you can justify access tokens, there currently isn't evidence > provided why we should explicity discourage. > > > On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt > <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote: > > > >> Am 08.02.2021 um 00:56 schrieb Warren Parad <wparad@rhosys.ch >> <mailto:wparad@rhosys.ch>>: >> >> >> >> I‘m therefore leaning towards explicitly stating in our draft >> that it is not intended to be used with refresh tokens. >> >> I'm not following, why explicitly state that it isn't intended. >> If an AS wants to provide a similar JSON response to a query with >> the refresh token, why not encourage that? > > Why should we encourage it? > >> >> >> >> Warren Parad >> >> Founder, CTO >> >> Secure your user data and complete your authorization >> architecture. Implement Authress >> <https://www.google.com/url?q=https://authress.io&source=gmail-imap&ust=1613346997000000&usg=AOvVaw267Z448csTGn3F6REIQ9pT>. >> >> >> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt >> <torsten=40lodderstedt.net@dmarc.ietf.org >> <mailto:40lodderstedt.net@dmarc.ietf.org>> wrote: >> >> Hi Andrii, >> >>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >>> <andrii.deinega@gmail.com <mailto:andrii.deinega@gmail.com>>: >>> >>> >>> Hi Torsten, >>> >>> thank you for your response. >>> >>> My use case is pretty straight forward >>> >>> An OAuth client queries the AS to determine the active state >>> of an access token and gets the introspection response which >>> indicates that this access token is active (using RFC7662). >>> >>> An OAuth client queries the AS to determine the active state >>> of a refresh token and gets the introspection response which >>> indicates that this refresh token is active (using RFC7662). >>> >>> An OAuth client queries the AS to determine the active state >>> of an access token and gets the introspection response (JWT) >>> which indicates that this access token is active (using this >>> draft). >>> >>> Now, an OAuth client queries the AS to determine the active >>> state of a refresh token (using this draft)... How will the >>> introspection response look like assuming that the client >>> provides the valid refresh token and technically, nothing >>> stops it from doing so. >> >> why should the state be provided as JWT?I think the plain >> JSON response is sufficient in that case. I also think using >> token introspection for checking the state of a token from >> the client side has limited utility. The definitive decision >> is always made when the client tries to access a resource. >> >> I‘m therefore leaning towards explicitly stating in our draft >> that it is not intended to be used with refresh tokens. >> >> best regards, >> Torsten. >> >>> >>> Regards, >>> Andrii >>> >>> >>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt >>> <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> >>> wrote: >>> >>> Hi Andrii, >>> >>> thanks for your post. >>> >>> The draft is intended to provide AS and RS with a >>> solution to exchange signed (and optionally encrypted) >>> token introspection responses in order to provide >>> stronger assurance among those parties. This is >>> important in use cases where the RS acts upon the >>> introspection response data and wants the AS to take >>> liability re the data quality. >>> >>> I’m not sure whether there are similar use cases if a >>> client introspects a refresh token. What is your use case? >>> >>> best regards, >>> Torsten. >>> >>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega >>> <andrii.deinega@gmail.com >>> <mailto:andrii.deinega@gmail.com>>: >>> > >>> > Hi WG, >>> > >>> > draft-ietf-oauth-jwt-introspection-response-10 states >>> that "OAuth 2.0 Token Introspection [RFC7662] specifies >>> a method for a protected resource to query an OAuth 2.0 >>> authorization server to determine the state of an access >>> token and obtain data associated with the access token." >>> which is true. Although, according to RFC7662, the >>> introspection endpoint allows to introspect a refresh >>> token as well. Hence, the question I have is how will a >>> token introspection response look like when the caller >>> provides a refresh token and sets the "Accept" HTTP >>> header to "application/token-introspection+jwt"? >>> > >>> > I expect there will be no differences, right? >>> > >>> > If so, I suggest to >>> > • replace "a resource server" by "the caller" in >>> section 4 (Requesting a JWT Response) >>> > • change "If the access token is invalid, >>> expired, revoked" by "If a given token is invalid, >>> expired, revoked" in section 5 (JWT Response) >>> > If not, my suggestion would be to clarify what the AS >>> should do when it asked to introspect the refresh token >>> in general and additionally, what should happen in the >>> same case based on the type of the caller from the AS's >>> point of view. >>> > >>> > Regards, >>> > Andrii >>> > >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613346997000000&usg=AOvVaw3ZHWt08dlcHAgxyfj2hrsX> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Vladimir Dzhuvinov
- [OAUTH-WG] JWT Response for OAuth Token Introspec… Andrii Deinega
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Andrii Deinega
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Warren Parad
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Torsten Lodderstedt
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Warren Parad
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Warren Parad
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Vladimir Dzhuvinov
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Andrii Deinega
- Re: [OAUTH-WG] JWT Response for OAuth Token Intro… Vladimir Dzhuvinov