Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Takahiko Kawasaki <taka@authlete.com> Thu, 23 April 2020 17:15 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 829AA3A0D57 for <oauth@ietfa.amsl.com>; Thu, 23 Apr 2020 10:15:24 -0700 (PDT)
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 SlCkJ9JjHVBR for <oauth@ietfa.amsl.com>; Thu, 23 Apr 2020 10:15:20 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 1FF713A0D23 for <oauth@ietf.org>; Thu, 23 Apr 2020 10:15:20 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id t63so7218680wmt.3 for <oauth@ietf.org>; Thu, 23 Apr 2020 10:15:19 -0700 (PDT)
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=ZpNf8yL8NZX/+xzasxcXVRCQyLeuZXYK1B8zEKr46l4=; b=FxQluEcIdlgz/8WMM6MvEI6HjIMIf16T6eFoHhVx2q+BoFbnvoaqKuoynT6mhDRa9m IzOhQJvdl0kHybdOcdOQo1RNesPrxb3bZKaJQ/FJvv4y5qM3uFXSP7ZGoYiuEuZhssoJ dGSyOdh4xrONUbGiNxkS6h+m/SVBj9N647IlOp5JdnCsuMbq7FsbuwJ8pCVYQpd/9Yhq 6riCBfjfasNd1OJvz29kXkMpmYOIf+z3qwAl0rC8fWKPBXa9Ww/4Xe1w0D53D9mHTHJA figfkKOpar3CG6EHMSRuk/rNe0wYvcMErhzSiK+Spy7UMcRPvb4SHc/7x1Jmik2KIBoS FZcQ==
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=ZpNf8yL8NZX/+xzasxcXVRCQyLeuZXYK1B8zEKr46l4=; b=um5r5uik2YldP/LCK/YnQwl79wJHdoh70Mt6zzC/LmktxVdgRFC0a/AHGLOgNMrBF8 uC7DHQrPua2hXy6zstd6DA3+r/tZPragzudrtwVoxXTOeeEehAfph9g9RtHMF/t3DvfY McFFW8rsprXG8YFS4P6tbk2FmgZ6vVHVq2p+0gCptWRzOu5qW3Cfc88e/MhoQASF/UuA +0L0UyxVDDmEOS3dcBLmleYHvGqypmKfOxtx8G2Kll9DWd6X7HriH+mLPdurQ0zRh7Ni Ygca5kSCji9hC4zd8r3daIZYp829cIcdBuegRKQekfpbYjvpyu/nl5OK/Zh8sN6Kbp/F SVlA==
X-Gm-Message-State: AGi0PuaDVUn3/eaOHVv0JJLqu6nHIPwu5Qc4Z+8CctrZMYE4LACvD4Vy 3gERqYsBUWMpmbVKCLHg1sUhwPcZVla0n5GI6hwVATQ/XAE=
X-Google-Smtp-Source: APiQypLoYR/UfMzJsY0DAPDDhLxfRXBTXNEgQixEa9HNCYqE2QHjjyCNttgnNHGH9nSmf5VPg7NOjm52ufUDkSDBk/c=
X-Received: by 2002:a1c:a549:: with SMTP id o70mr5150906wme.179.1587662117987; Thu, 23 Apr 2020 10:15:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com> <085301d616e8$21029750$6307c5f0$@auth0.com> <CAO7Ng+t-337n-EdGMRGTx4-oP3Z4JcCf6Qx6ZQK8ivuKTasAAg@mail.gmail.com> <MWHPR19MB15017E10AD0880993F02B44CAED50@MWHPR19MB1501.namprd19.prod.outlook.com> <CAO7Ng+sXD0rZFUYnEtSNtXaYNQV97HUQZ2TdzQRxMVdfU=NfBQ@mail.gmail.com> <MWHPR19MB150196432E117F2C47B077D1AED50@MWHPR19MB1501.namprd19.prod.outlook.com>
In-Reply-To: <MWHPR19MB150196432E117F2C47B077D1AED50@MWHPR19MB1501.namprd19.prod.outlook.com>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Fri, 24 Apr 2020 02:15:06 +0900
Message-ID: <CAHdPCmN0RpA9skSX8nLODrDp=y5dP8v2Lx90rKisUcXwE9OzUw@mail.gmail.com>
To: oauth <oauth@ietf.org>
Cc: Dominick Baier <dbaier@leastprivilege.com>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000090fffc05a3f8641a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access 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: Thu, 23 Apr 2020 17:15:30 -0000

First, to make the discussion fair, I think I should share what I observed
today. Auth0's client_credentials flow requires an "audience" parameter,
which is equivalent to the "resource" parameter defined in RFC 8707, and
embeds the client ID in the generated JWT access token as the value of the
"sub" claim.

My opinion as a software engineer is as follows.

[aud]
The "aud" claim should be null or absent when the "resource" parameters are
not given in an authorization request. It is not good to introduce
inflexible rules to determine the default value for the "aud" claim based
on the "scope" parameter.

[sub]
The "sub" claim should be null or absent when a resource owner is not
involved in an authorization request. To be concrete, the "sub" claim
should be null or absent in the client credentials flow. The spec draft
says in "5. Security Considerations" as follows.

- - - - - - - - - -
Authorization servers should prevent scenarios where clients can affect the
value of the sub claim in ways that could confuse resource servers.  For
example: if the authorization server elects to use the client_id as the sub
value for access tokens issued client credentials grant, the authorization
server should prevent clients to register an arbitrary client_id value, as
this would allow malicious clients to select the sub of a high privilege
resource owner and confuse any authorization logic on the resource server
relying on the sub value.  For more details please refer to section 4.13 of
[OAuth2.Security.BestPractices].

To preventing cross-JWT confusion, authorization servers MUST use a
distinct identifier as "aud" claim value to uniquely identify access tokens
issued by the same issuer for distinct resources.
- - - - - - - - - -

However, the attack vector is brought about merely by introducing the
following rule defined in "2.2. Data Structure".

- - - - - - - - - -
In case of access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub SHOULD
correspond to an identifier the authorization server uses to indicate the
client application.
- - - - - - - - - -

If the rule is not introduced, the attack vector disappears and the "aud"
claim doesn't have to be mandatory.

Finally, to make the discussion fair, I should also mention that I myself
is a co-founder of Authlete, Inc. that provides an implementation of OAuth
and OpenID Connect. My thoughts about implementations of access tokens are
publicly described here:

OAuth Access Token Implementation
https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci <vittorio.bertocci=
40auth0.com@dmarc.ietf.org> wrote:

> Ouch! Sorry 😊 fixed
>
>
>
> *From: *Dominick Baier <dbaier@leastprivilege.com>
> *Date: *Tuesday, April 21, 2020 at 10:23
> *To: *oauth <oauth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>,
> Vittorio Bertocci <vittorio.bertocci@auth0.com>
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Oh and while we are at it - could you also fix the typo in my name? Thanks
> ;)
>
>
>
> ———
>
> Dominick Baier
>
>
>
> On 21. April 2020 at 09:43:49, Vittorio Bertocci (
> vittorio.bertocci@auth0.com) wrote:
>
> This is a great point. In my head I just considered the OIDC semantic and
> thought only of highlighting the app identity case, but you are absolutely
> right that not mentioning the user case at all is confusing. I added the
> language you suggested at the beginning of the sub definition.
>
> Thanks!
>
>
>
> *From: *Dominick Baier <dbaier@leastprivilege.com>
> *Date: *Monday, April 20, 2020 at 22:54
> *To: *oauth <oauth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>,
> "vittorio.bertocci@auth0.com" <vittorio.bertocci@auth0.com>
> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application.
>
>
>
> Maybe I am missing something, but does it say anywhere what to explicitly
> do in the case of an access token where a resource owner is involved?
>
>
>
> There’s some language that seems to imply that, e.g.:
>
>
>
> as this would allow malicious
>
>    clients to select the sub of a high privilege resource owner
>
> I would have expected to see something stronger like above just -
>
>
>
> In case of access tokens obtained through grants where a resource owner is involved, such as the authorisation code grant, the value of sub SHOULD correspond to the subject identifier of the resource owner.
>
>
>
> If this spec is about interop, I think this should be at least a
> recommendation...
>
>
>
>
>
> ———
>
> Dominick Baier
>
>
>
> On 20. April 2020 at 09:48:51, vittorio.bertocci@auth0.com (
> vittorio.bertocci@auth0.com) wrote:
>
> Thanks Dominick for your comments!
>
> Inline
>
>
>
> *>** All other OAuth specs make a very clear distinction between users
> and client.*
>
> There’s a nuance worth highlighting here: sub != user. In previous
> discussions on this topic it has been brought up that the JWT spec defines
> sub as identifying the principal that is the subject of the JWT, and that’s
> not necessarily limited to users.
>
> However I get the potential confusion, and I am happy to add clarifying language if you have specific passages in the space you are particularly worried about: however I feel the matter is addressed upfront by the language in Section 2.2. in the sub entry, “In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application.“ and Section 5 has an entire paragraph discussing things to watch out in assigning sub values in the app identity case. Feel free to suggest additional language if you want to clarify further.
>
>
>
> *> sub has a different semantic here as in OIDC*
>
> The  spec refers to RFC7519 in the sub definition in 2.2, rather than
> OIDC, to preempt that concern and keep the original sub semantic available.
>
>
>
> *>** I am not fully clear why aud is required.*
>
> Aud is there mostly because of three reasons:
>
> ·         Many existing specs postulate its existence in the token. No
> one declares it as a proper MUST (apart from the BCP, but that’s partial)
> however I think its importance comes across..
> -Bearer token usage RFC6750 calls it out (in threat mitigation) as the
> mechanism to prevent token redirect (and adds scope restriction as also
> important, however here we make it optional to acocut for non-delegations
> scenario).
> -Resource indicators RFC8707 refers to the same section of RFC7519 as one
> of the assumptions that must hold to prevent bearer tokens misuse
> -BCP225 makes aud mandatory for AS which can issue JWTs for more than one
> app
>
> ·         Apart from Ping, for which some of its examples are without aud
> (but also without identifying scopes, given that the one I retrieved had
> only “openid”), all of the sample JWT ATs I received from vendors all
> featured an aud. I know one shoulnd’t overindex on those examples, but
> together with the above it seemed to point to something universally useful.
> One possible reason is that use of a format for the AT is correlated with
> topologies where AS and RS are separated by some boundary (network,
> logical, business, code factoring, etc) hence identifying the resource
> seems like a natural need. Again, not an iron clad law, but an indication.
>
> ·         A lot of people repurpose existing libraries for the JWT AT
> case, and some people even sends id_tokens in lieu of ATs. That doesn’t
> mean that we should condone any bad practices, but in tis particular case
> it suggests that lots of developers already expect/can handle an audience
> in the JWT used to call their API
>
> None of those are a slam dunk argument for mandatory, but I find them
> compelling enough to simplify validation and just require an aud to be
> there, as opposed to introduce complications that make it conditional to
> the presence of scopes or other disambiguation. One reason I feel pretty
> good about that is that adding a default audience isn’t very hard if any of
> the above assumptions end up not being true for a particular case
>
>
>
> *> What’s the rationale for using iat instead of nbf. *
>
> That’s just straight from OIDC ID_tokens, and the considerations about
> repurposing existing logic. I see there’s a thread on this specifically,
> let me answer further on that branch.
>
>
>
> *> This spec feels somehow in between a profile and a BCP*
>
> You are right that this spec attempts to go beyond just declaring a
> layout, and I agree this means that this profile will not apply to
> absolutely everyone. The reason I tried that route (at the cost of working
> way harder in the last year for reaching consensus than if we would have
> just listed the possible content), is that I often observe implementers
> make questionable choices because of the large leeway specifications allow.
> My hope was that the scope of this profile was small enough to make that
> extra level of guidance achievable, whereas trying to do the same with a
> larger spec would have been prohibitively expensive.
>
> I believe things worked out well so far: we had lots of constructive
> discussions, and I ended up relaxing A LOT of the constraints I was
> originally envisioning. Nonetheless, my hope is that we identified the
> right set of guidelines that will help people actually interoperate out of
> the box for the most basic/common scenarios, as opposed to complying with
> the letter of the spec but still having a lot to figure out out of band.
>
>
>
> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Dominick Baier
> *Sent:* Thursday, April 16, 2020 12:10 AM
> *To:* Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; oauth <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Since this is the last call, I thought I bring up some of thoughts /
> concerns. Some of them have been discussed before.
>
>
>
> *client_id vs sub*
>
> I am still not entirely happy with the “re-purposing” of the claim types
> based on flow.
>
> If the intention is, that sub expresses the entity against which the
> resource will do authorisation (and that might be a client or a user) - I
> get it (and maybe it should be stated like that) - but
>
> this thinking reminds me of the old AD days where there was no distinction
> between user and service accounts (something that has been fixed IIRC in
> Windows Server 2012 R2).
>
>
>
> All other OAuth specs make a very clear distinction between users and
> client.
>
>
>
> Furthermore it says
>
>
>
> "Authorization servers should prevent scenarios where clients can
>
>    affect the value of the sub claim in ways that could confuse resource
>
>    servers.”
>
>
>
> If we keep that dual semantics of the sub claim - it must be clearly
> stated, that subject ID and client ID are now in the same collision domain.
> So when an AS / OP creates them, they need to be unique across user ids and
> client ids.
>
>
>
> Maybe it should be also explicitly mentioned that sub has a different
> semantic here as in OIDC - even though a majority of the software built
> today will use them together.
>
>
>
> *audience claim*
>
> I am not fully clear why aud is required. OAuth itself does not have a
> notion of an audience (in the JWT sense) - they have scopes (which is very
> similar). But in simple scenarios where resources don’t exist, you'd need
> to make up an audience just to fulfil this requirement. And in many case
> this will be either static or just repeat the scope values. What’s the
> value of that?
>
>
>
> If the concept of resources are used, I absolutely agree that aud should
> be used too. But I wouldn’t make it required.
>
>
>
> *iat vs nbf*
>
> What’s the rationale for using iat instead of nbf. Aren’t most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?
>
>
>
> *General*
>
> This spec feels somehow in between a profile and a BCP. On one hand you
> define some claims and their semantics (good) - on the other hand there is
> some prescriptive guidance and maybe over-specification. My concern is,
> that in the end no-one will fully comply with it, because it doesn’t work
> one way or the other for them.
>
>
>
> I know we just went though the discussion to make certain claims required
> as opposed to optional - but maybe less is more.
>
>
>
> Tbh - the most valuable part of the doc to me is the definition of the
> “at+jwt” typ. For the rest I’d rather like to see just some standard claims
> and IF they are used, which semantics they have.
>
>
>
> cheers
>
> ———
>
> Dominick Baier
>
>
>
> On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.ietf@gmail.com)
> wrote:
>
> Hi all,
>
>
>
> This is a second working group last call for "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06
>
>
>
> Please send your comments to the OAuth mailing list by April 29, 2020.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>