Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
Vittorio Bertocci <Vittorio@auth0.com> Mon, 22 July 2019 19:33 UTC
Return-Path: <vittorio.bertocci@auth0.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 97CA212004E for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 12:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=auth0.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 YbheD-cw2NDo for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 12:33:08 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 D2B2012012E for <oauth@ietf.org>; Mon, 22 Jul 2019 12:33:07 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id t28so38729399lje.9 for <oauth@ietf.org>; Mon, 22 Jul 2019 12:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a21M2uSSBfcuiPmj3WX4KTS7GagdO42IY/b6bagaMas=; b=pdLAhyaMmz1FNxOc7z9D0XHd8sHV//BM4O7xW3KYDyHYPJDvG6IrC7A6tmhBcyHOkP feNCoz0dE+7mpUlfW38VZSgB0M6NF8nJZ1+Q1KC2Uvjd7HLBt3fgC5zR+5Iel0bwe0Uh MKlYrQ1ADA/Oti8y6oAZ/kr3km4QXNYYSjkOujsglh6wFbeysdyE1LcbIdZgjrhwXQV8 wZfpctvACARBQJSdfljMMKfnwz2SnO5r6HCq5fEwu8fVwpkXTgL8U9g1GJjKIoSbGk6F 8jK4UScaG9RgqHjTHz6H+vCROJT1nxFWtOaFn1ZXWS49Mv9obXln+dvZoRlpA+hNaUqj 3MaQ==
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=a21M2uSSBfcuiPmj3WX4KTS7GagdO42IY/b6bagaMas=; b=aDfTWe01FGXU67qGBhWc1iqcAg/MKwTgDAKmSy+E88x8K1kzZKq9OcDopKFBQohHUh 7tIa+owK84n401BTN6x/jatAZ+6h/dyFuXc41VGG7VesNKZrRjqdtGeo1ICjJVfSE24+ V9r8h5ao3z/jUO7ImJbJjzGDERpmyVovVJRSOYpIrjQAtPbEnzThR6mnzKR9uyMG2aVm oRQnLBz4ecHQ5k8pEc19cV58+cfPJIaIK8dwtn6Ae8GcWtX7kxhP68baKDJciBLuOM4M fhx7XxFKRFXJm7rDX5ydOGWhbHQYFjpJerRvbFSjXyEWwBdvuVhpgRRs5/N3pXLRGyrq epzw==
X-Gm-Message-State: APjAAAXFH5Z5YwyJcTHKQOk5z/dZp4eTo6ZyRMf781BOZFFupkDJTOPm zqZ0DMB7Ll1+Gcp/Wa+3mACXM26L0DS3Uuf4AWwLKxEiLMF5MDtC
X-Google-Smtp-Source: APXvYqwAmbesGrA6v8SHUTB4RlIMZthMkm4Pt5OQ12SRAZa4ja9CAQzsg8TcKheXOAdudy93ZNYvmwwxRGv/L7FcXrI=
X-Received: by 2002:a2e:2d12:: with SMTP id t18mr20166151ljt.175.1563823985908; Mon, 22 Jul 2019 12:33:05 -0700 (PDT)
MIME-Version: 1.0
References: <156371372426.20589.10365011724092335159@ietfa.amsl.com> <4A5EA92D-0B76-4383-9827-CF49CC363AA6@lodderstedt.net> <CAO_FVe4rYRBnZ7_unzDVM9S7eEbPBc-hN0UeyFWJ_UfeoUhRGg@mail.gmail.com> <5078F754-28C0-4D19-8F65-FC9F7C8A8DEF@lodderstedt.net>
In-Reply-To: <5078F754-28C0-4D19-8F65-FC9F7C8A8DEF@lodderstedt.net>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Mon, 22 Jul 2019 12:32:56 -0700
Message-ID: <CAO_FVe4v7APcsqjM2wuJdTs30G0f=hOaQb9_ZpNCE_2aE-b=Zg@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002bf513058e4a252d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/idFmb-4Rbna8NkjsgxWR97w-npw>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
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, 22 Jul 2019 19:33:12 -0000
> Additionally stating that unique audiences shall be used for different services should be ok. Fair! I'll add language to that effect in section 5 and update the draft before Friday. thanks! V. On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > > > > On 22. Jul 2019, at 17:13, Vittorio Bertocci < > vittorio.bertocci@auth0.com> wrote: > > > > Thank you Torsten for the prompt review and insightful comments! > > > > 2.2.1 - excellent point. I added the suggested language. > > > > 2.2.2 - interesting. I did think of cases similar to profile in OIDC, > where the effect of the request is influencing the layout of the resulting > idtoken, but concluded that it didn't apply as is for access tokens. Given > that you have direct knowledge of such cases in the wild, I am happy to > relax the MUST into a SHOULD. > > > > 5. - this is going to be problematic in the wild. For example, in the > azure AD world a registered application can play both the role of an API > and a client; and requests for tokens targeting the app can use any > identifier assigned to the app. That means that although idtokens will only > be issued if the request identifies the client via clientID, access tokens > requests for it will be honored (and reflected in aud) both in the case the > resource parameter contains the clientID or the API URI of the target > application. > > Interesting and (in my opinion) reasonable. Out of the top of my head I > don’t see how this has a negative security impact since the recipient is > always the same service. > > > In fact I suspect that the most recent version of the service uses the > clientID as preferred identifier, if not the only one. Mike/Tony can > confirm or deny. > > As a compromise, we could add language in the spec that recommends the > use of a unique audience when viable, as an extra measure in case the typ > value isn't honored. WDYT? > > Having a unique audiences at least for different services is key. > > In fact, I’m concerned about JWT confusion in OIDC RPs in the wild that do > generally not honor the type (as long as we do not update OIDC Core to > require this and it is being adopted). I think since your draft requires > both, iss and aud to be present, this threat is being dealt with. > Additionally stating that unique audiences shall be used for different > services should be ok. > > > > > > > > On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi Vittorio, > > > > thanks for contributing this specification. It fills a further gap in > the OAuth universe :-) > > > > Here are my comments: > > > > - 2.2.1 there are other sources for identity claims, e.g. > https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. > > > > I recommend to open the clause > > > > "Any additional attributes whose semantic is well described by the > > attributes description found in section 5.1 of [ > > OpenID.Core] SHOULD > > be codified in JWT access tokens via the corresponding claim names in > > that section of the OpenID Connect specification. The same holds for > > attributes defined in [RFC7662]." > > > > by adding > > > > "and other identity related specifications.” > > > > Alternatively, the draft could also refer to the IANA “OAuth Token > Introspection Response” registry as source for JWT claims. > > > > - 2.2.2. > > > > "If an authorization request includes a scope parameter, the > > corresponding issued JWT access token MUST include a scope claim as > > defined in section 4.2 of [TokenExchange]." > > > > Why do you establish such a strong link between the scope in the > authorization request and the access token? I’m aware of implementations > that map scope values to audience values and therefore do not carry the > scope value to the resource server. I suggest to soften this requirement > and make it a recommendation. > > > > - 5. > > > > "The JWT access token data layout described here is very similar to the > one of the id_token as defined by [OpenID.Core]. Without the > > explicit typing required in this profile, in line with the > recommendations in [JWT.BestPractices] there would be the risk of > > attackers using JWT access tokens in lieu of id_tokens." > > > > I like this practice but it is not established yet in the OpenID Connect > universe. This means any OIDC RP will process an access token because it > will just ignore the type header. > > > > draft-ietf-oauth-jwt-introspection-response therefore gives > recommendation on how to use iss and aud claim to prevent JWT abuse ( > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04#section-6.1). > > > > > Mapping this pattern to JWTs as access token requires that there must > not be the same aud value for a resource server and any other JWT consumer, > e.g. an OpenID Connect RP. > > > > kind regards, > > Torsten. > > > > > On 21. Jul 2019, at 14:55, internet-drafts@ietf.org wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > > > Author : Vittorio Bertocci > > > Filename : draft-ietf-oauth-access-token-jwt-01.txt > > > Pages : 15 > > > Date : 2019-07-20 > > > > > > Abstract: > > > This specification defines a profile for issuing OAuth2 access tokens > > > in JSON web token (JWT) format. Authorization servers and resource > > > servers from different vendors can leverage this profile to issue and > > > consume access tokens in interoperable manner. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-01 > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > >
- [OAUTH-WG] I-D Action: draft-ietf-oauth-access-to… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Petteri Stenius
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-acces… Vittorio Bertocci