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

Dominick Baier <dbaier@leastprivilege.com> Mon, 20 April 2020 06:52 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 713663A1281 for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 23:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.023
X-Spam-Level:
X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MBhjhKKY9phT for <oauth@ietfa.amsl.com>; Sun, 19 Apr 2020 23:52:10 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 C769A3A1282 for <oauth@ietf.org>; Sun, 19 Apr 2020 23:50:39 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id w24so7598435qts.11 for <oauth@ietf.org>; Sun, 19 Apr 2020 23:50:39 -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 :cc; bh=WP+sEblzVrP/Ar5G1r3kd70m2iHGuEDJyGGj+MZ7gHI=; b=0S/G/A29RVjT78l5F2lQPN3NSBQeaICuweESSOeQvV9ToPyhggY6XOPF3gKCAc3l9r Iu29q+NupVRQQ1UptBRanJg5kRKHlOpC8GOD9OscHDNZ6exVEKq6W3AUfrPMOFfpDkKT Wq1JRp1axZ3NN/c2RP8Osl4I+m5spzm7DxqrXHSVXXUoIo/AxJ8kymMBU3lhCNO7zdJO 303ExivqmLH/EMMwzy/xYlYoLIl309FCxXJvyvNTVwEB+iqMX+gvqwjOm5X5q/s/SDmO c5Xzpd49j3WNveYnrOou7lrjZaX+h71UzFJr4bD/CX/hHpNFcrWCWt9B1lnfKaP3MhBr lKrQ==
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:cc; bh=WP+sEblzVrP/Ar5G1r3kd70m2iHGuEDJyGGj+MZ7gHI=; b=ofrcwEoEw1ugE+scKIcmGtVCvlvgYL/vfD2HdEyCw+BsDTzsaCF6Fcpri+sEHGkK3L L2EZ7xS7g4EbfKKJyCkknF/3+x7C9Aj+zzZrfbMk9Es7fGAAPZvM9DkKX7Dcw2Udbo8Z 1LhtL5DJieSF+mgF5/k8ZOg3Pqc8QuXYI98ZScpAF4j+Uok9eV8MDePemM7KVMTFhoVh b7rSk4uD36tS4x5KqQD/e2CZH/ZT5Q7W5z4pemkczFYpPoY6l4iiLAM96MI9l8ZlVhCe YAp4A+jZhtyuug2h8dK7jZNT3hmRdnPkFz4JU452MmVdx6KcsqWmStU6eqbFByMTVGqF Vxlg==
X-Gm-Message-State: AGi0Pua5AGTzDzu2qt1xnYnIolEjGlNBpgGGyIUKVG78glgSemtEwOWi KbAuU72o33o8/FZArOTtdedYEopKF3Wy/VOr2CaTJ1s=
X-Google-Smtp-Source: APiQypJU33V4jpXINOC4FlqXF7i62meU1crUNjs54Zo0zTtFmef5KdPfxPeDCEp4b/KE2NkuH0uDbK/BwvXFIH7IJWw=
X-Received: by 2002:ac8:17c7:: with SMTP id r7mr14267421qtk.356.1587365427896; Sun, 19 Apr 2020 23:50:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Apr 2020 02:50:27 -0400
From: Dominick Baier <dbaier@leastprivilege.com>
In-Reply-To: <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com> <d9b766d0-75dc-926b-8c8c-951f1d5aface@connect2id.com> <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com>
MIME-Version: 1.0
Date: Mon, 20 Apr 2020 02:50:27 -0400
Message-ID: <CAO7Ng+tJVsO4GZZNmNx2-nirWsjQcZxu0T9g4w_95vkPANSSmQ@mail.gmail.com>
To: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth@ietf.org, Vittorio Bertocci <vittorio=40auth0.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000075750705a3b350c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HIdhWdzM0Lz6Yqq3IObZd4FXgkU>
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: Mon, 20 Apr 2020 06:52:26 -0000

Just a quick data point -

The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.

I guess my real question is - what’s the difference between the two
practically speaking - and shouldn’t be the more common (aka supported by
most libraries) be used?

———
Dominick Baier

On 20. April 2020 at 06:59:47, David Waite (
david=40alkaline-solutions.com@dmarc.ietf.org) wrote:

There are a number of ambiguities and statements around using JWTs in
various contexts:

1. Some implementations interpret “iat" to also have the meaning of “nbf”
in the absence of “nbf”, although this is AFAIK not prescribed by any spec
2. The DPoP draft’s client-generated tokens have the resource servers use
their own nbf/exp heuristics around “iat”, since the tokens are meant for
immediate one time use by a party that may not have clock synchronization.
3. There are recommendations in the JWT profile for OAuth that the AS may
reject tokens based on an “iat” too far in the past or “exp” too far in the
future, but not that “nbf” was too far in the past or that the interval
between nbf and exp was too large.

The JWT spec also allows implementers to provide some leeway for clock
skew. Presumably this meant validators and not JWT creators, although there
is history of messages setting similar values to account for clock skew
(e.g. SAML IDPs setting notBefore to one minute before issuance and
notOnOrAfter 5 minutes after issuance).

-DW

On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com>
wrote:

On 16/04/2020 10:10, Dominick Baier wrote:

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

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

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