Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection
Takahiko Kawasaki <taka@authlete.com> Mon, 02 March 2020 17:27 UTC
Return-Path: <taka@authlete.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 C8C713A0D48 for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 09:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.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 EVv2Lr-H0i0J for <oauth@ietfa.amsl.com>; Mon, 2 Mar 2020 09:27:23 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 C6F303A0D49 for <oauth@ietf.org>; Mon, 2 Mar 2020 09:27:22 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id q8so774916wrm.4 for <oauth@ietf.org>; Mon, 02 Mar 2020 09:27:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iCwqbRsDwvulJusW52GYcjh+9AnhYdHkLcAh0aOjGuM=; b=vvZsbV+5ZEKNOqNYP3/RFWPYE7YJtcf74SZFWwI8WvDJcNXqjKXSYhFwGCiR+fmPYh jWolZge+goV0eAqLx7ON5cocOUz5zhlVteZbUru2b2CT5rW2lFtPlyz47wXProb5srJp j3sA4kzJeuLt86jX6dscyRFuBfziMP9pwP3bvKztjv/TKzg/CEyIQRiHSoeQKEQGBlPW iX6NAxDXc12ciS7/zYnjvdnL9SOLmGg17xyviaPIXJi85Jr3wAC7M3yYfinK2CtHjf9p DYGoDjLm2hVIVz2Ncyo+uNBacLjJ6GAho3T53GBPh9MGAIrhtF0WmxMqtzYM1WeUbfhh d3DA==
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=iCwqbRsDwvulJusW52GYcjh+9AnhYdHkLcAh0aOjGuM=; b=cWJGT00EpZKEGKn4eyZx8zij7iAjJLTI4WGTUCcNXQrYpR8n8a7ePxx6jhwxra6pof qQUQshtIutSRkbfrIbiaa3bBnIXKiaM2O8x34ZqsZWRQajDI35XLhjuwI77oeZUt4+Op ZDRsIyBP3jQ8yo9YhqPu0bjvaGizQRlZWtKzKvP6M04Hqz975vu15I+b0djFHhEQeUW0 0CVyYBBmbpoXHA+cgRnLJkqAxOejI5qwbmEUiSLIzghXuAht8igbGW1fuPXQuIth0jDz ygQCG601+2warVOrlA7KKTr6iJon83ldQGt4MiOnmsugA9X7bCC7Yve+vij2FO/HmyYY UuUg==
X-Gm-Message-State: ANhLgQ3FPw8vAMobnH545lwYnqquJiAaVj7mBmwx0hP607XnzAEuPyZQ D8sVIAdeJbFW8Bt9XMdhrBNnfXF3/8nhEvLxpnA4kg==
X-Google-Smtp-Source: ADFU+vt/OCxOG33CCU7Pwqh8eByYL3v5u6z/iddsbDxO21aOdzAI+6UdPkoNQMpLKyRkn6vLXkzJpKkRFTOU+WEiLUE=
X-Received: by 2002:adf:b601:: with SMTP id f1mr664575wre.103.1583170041217; Mon, 02 Mar 2020 09:27:21 -0800 (PST)
MIME-Version: 1.0
References: <CAHdPCmPCMJqH-aOC2SjFhGd9sjd01xw=VEj5y1jA5nRNRhu4EA@mail.gmail.com> <5514F7A5-D87D-42D8-9DA0-9ADCDD75D989@lodderstedt.net> <CAHdPCmO7nfG6jXgo56HdUmmz8iu0O-Dd-sPO3pc_-6MWCheOMQ@mail.gmail.com> <13A6E943-3C58-4064-9DE4-AFB1F351BD47@lodderstedt.net>
In-Reply-To: <13A6E943-3C58-4064-9DE4-AFB1F351BD47@lodderstedt.net>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Tue, 03 Mar 2020 02:27:36 +0900
Message-ID: <CAHdPCmP112ag5cebTJ2-T31j3gRrDdoVme-jXeWVnLskn475YQ@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary="000000000000ed1fa0059fe27fd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1AY3PTO6G7FPJ0Xi9fwhVJN31C0>
Subject: Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection
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, 02 Mar 2020 17:27:26 -0000
>From RFC 7662, Section 2.1 *To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.* "Some form of authorization" may not be able to distinguish API callers. For example, if one pair of API key and API secret is shared by multiple resource servers. Even if the number of "resource" request parameters is one, its value is not necessarily the identifier of a resource server. What if " https://rs.example.com/resource1" is given as "resource"? Which value should "aud" hold, "https://rs.example.com/resource1" or " https://rs.example.com"? If the format of access tokens is JWT, when an authorization request includes "resource=https://host1.example.com/resource1" and "resource= https://host2.example.com/resource2", the resultant access token will have "aud" like below. "aud" : [ "https://host1.example.com/resource1", "https://host2.example.com/resource2" ] However, if your logic applies, the introspection response for the access token will include a different value for "aud". This behavior is confusing. Because "some form of authorization" is performed when an introspection call is made, I don't think it's necessary to modify the value of "aud" per API caller. Anyway, the root cause is that (a) "aud" in RFC 8707 and (b) "aud" in draft-ietf-oauth-jwt-introspection-response (in general "aud" in JWT) are different concepts but they share the same name. Any workaround without solving the root cause will bring about unhappy future. Taka On Tue, Mar 3, 2020 at 1:44 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > Hi Taka, > > I see, the audience is multi value. In my impression both specs assume a > single value audience. > > But I think we can handle this as follows: Since the caller of the > introspection respect is a single RS, the AS first needs to map & check the > resources associated with the underlying access token against that caller. > The RS is authenticated at the introspection endpoint using a client_id > (and some credential), so the AS needs to map the client_id to resource > identifier. If the result is in the set of the resources associated with > the underlying access token, the AS can create an Introspection Response, > which only contains this particular resource. > > What do you think? > > best regards, > Torsten. > > > On 2. Mar 2020, at 17:31, Takahiko Kawasaki <taka@authlete.com> wrote: > > > > Hi Torsten, > > > > For example, if an authorization request includes two "resource" request > parameters like below, > > > > resource=https://host1.example.com/resource1 > > resource=https://host2.example.com/resource2 > > > > RFC 8707 expects that the value of "aud" in an introspection response > look like the following. > > > > "aud" : [ > > "https://host1.example.com/resource1", > > "https://host2.example.com/resource2", > > ] > > > > How does the implementation of the introspection endpoint insert the > identifier of the resource server (the API caller?) into the "aud" array > above? In other words, what is the expected resultant value of the "aud" > array in this case? > > > > Taka > > > > > > On Mon, Mar 2, 2020 at 10:54 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi Taka, > > > > > On 1. Mar 2020, at 08:10, Takahiko Kawasaki <taka@authlete.com> wrote: > > > > > > Hello, > > > > > > I'm wondering if the following conflicts in "JWT Response for OAuth > Token Introspection" (draft 8) have already been pointed out. > > > > > > RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an > introspection response hold the values of the 'resource' request > parameters, whereas "JWT Response for OAuth Token Introspection" says that > 'aud' MUST identify the resource server receiving the token introspection > response. The definitions conflict. > > > > RFC 8707 states > > > > The authorization server may use > > the exact "resource" value as the audience or it may map from that > > value to a more general URI or abstract identifier for the given > > resource. > > > > draft-ietf-oauth-jwt-introspection-response-08 states > > > > The value of the "aud" claims MUST identify the resource server > > receiving the token introspection response. > > > > So RFC 8707 gives choices of how the resource server might be identified > and draft-ietf-oauth-jwt-introspection-response-08 says the AS must > identify the RS without prescribing any particular way. So basically you > can use the advice given by RFC 8707 to implement the requirement stated > by draft-ietf-oauth-jwt-introspection-response-08. > > > > I don’t see a conflict. > > > > > > > > RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an > introspection response indicate when the access/refresh token was issued, > whereas "JWT Response for OAuth Token Introspection" says that 'iat' > indicates when the introspection response in JWT format was issued. The > definitions conflict. > > > > I will come back to this issue in an answer to Filip’s post. > > > > best regards, > > Torsten. > > > > > > > > Best Regards, > > > Takahiko Kawasaki > > > Authlete, Inc. > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > >
- [OAUTH-WG] Conflicting definitions in JWT Respons… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Filip Skokan
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Justin Richer
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Justin Richer
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Justin Richer
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Filip Skokan
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Filip Skokan
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Benjamin Kaduk