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

Dominick Baier <dbaier@leastprivilege.com> Tue, 21 April 2020 05:54 UTC

Return-Path: <dbaier@leastprivilege.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 05BFE3A0A51 for <oauth@ietfa.amsl.com>; Mon, 20 Apr 2020 22:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=leastprivilege-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 3nsTECPSIDxs for <oauth@ietfa.amsl.com>; Mon, 20 Apr 2020 22:54:30 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 C56443A0A64 for <oauth@ietf.org>; Mon, 20 Apr 2020 22:54:29 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id v18so5999448qvx.9 for <oauth@ietf.org>; Mon, 20 Apr 2020 22:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=rV/Cxv40bMifdetXGCdDqkgRSkpb4qzzRJ3Yg1rOiuU=; b=Jw7QBReY/wkti346INhxtnNfdxiPL/MMS+e6SXIxOwDlhx6ZOYJJIpmE8MxXdcPbwD Jky0rhfNiAxN6h04mLdUB4nslZFiVB83TpgOjSSetifzo7GjWvwhbHcnA5eUGKIh/01G VzxP2Oiv6UHpWHcRvw5vHj9J1PuBRvVF+vkJq8ceQYllQyfqc/s/DpUKrOEvUeixse1T TwGWSEkTYbHbLRFi13ezvY1kmG+bQEV3oXcSNxZN5xEKYwKxTl8Nf0MDZvl2fvq55Ejm vehckL0LGDWJNoTivDmMQ2baf9HUCqj+2rU+5xKtNC4xaaWlA5m3nE4ltK26leLl1bfG 0JGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=rV/Cxv40bMifdetXGCdDqkgRSkpb4qzzRJ3Yg1rOiuU=; b=RQkaCj+GTyXjYWID+Sa2XwrI1KQNamXem6puF1c4K6nIWFJE/ruc/baG/argxUIMzB f/MRembaZFYpmhh/CgnHdz/vOjaZs+5qem+cMJYw1MxUiqTK1y+Dl/7PxV5LLj21peVO CGu6EPkLt5Qoswd3ozscS9a272BUK7s0MrjBFnwFBSbq6LMgGnAvBJVowBrtI+xqXA0W KFNB6fCFe8XqlL6B5b6pdjR9/sEdOEa6QXjGVhgklGqsDz9PZIUvSIVWhvo86NK10EwL PBidSYL8t3gItXbEMx2VWtNFzM+pXr8dvK7YNOe7xRM/a3MsiQsUIAUodbmdUkwManhP Yqsw==
X-Gm-Message-State: AGi0PuZa7SGp2NGf9Il6Ruk+nKTyJzuSsrsgelzUdgDdlQ/3nVgeE8bg CoE6zkzbWMUvwAMPpKC6rP/5Y2aQNxy69PEluxWrUJ8=
X-Google-Smtp-Source: APiQypIaonlQay6t2iRr4MT15X4v7mND3Pz/+RSJrPo6TmU05EtFggpdxwSyBEQYCxiZJbwKNaFeS3EexrxAVY5KlKg=
X-Received: by 2002:ad4:4d06:: with SMTP id l6mr4996069qvl.34.1587448467936; Mon, 20 Apr 2020 22:54:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 21 Apr 2020 01:54:26 -0400
From: Dominick Baier <dbaier@leastprivilege.com>
In-Reply-To: <085301d616e8$21029750$6307c5f0$@auth0.com>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com> <085301d616e8$21029750$6307c5f0$@auth0.com>
MIME-Version: 1.0
Date: Tue, 21 Apr 2020 01:54:26 -0400
Message-ID: <CAO7Ng+t-337n-EdGMRGTx4-oP3Z4JcCf6Qx6ZQK8ivuKTasAAg@mail.gmail.com>
To: oauth <oauth@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, vittorio.bertocci@auth0.com
Content-Type: multipart/alternative; boundary="00000000000007eb4405a3c6a66b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ovyvsTrK2d6VDreyYMn9lypnrZo>
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: Tue, 21 Apr 2020 05:54:38 -0000

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