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