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 07:43 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 1331B3A1375 for <oauth@ietfa.amsl.com>; Mon, 20 Apr 2020 00:43:19 -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 G4Z8sOM0TXgh for <oauth@ietfa.amsl.com>; Mon, 20 Apr 2020 00:43:17 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 07F913A1373 for <oauth@ietf.org>; Mon, 20 Apr 2020 00:43:16 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id g74so9537615qke.13 for <oauth@ietf.org>; Mon, 20 Apr 2020 00:43:16 -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=lkFncC2ejP5EBjl7iBudwspHQQVTqvvWC5ARDznQQAc=; b=c0VA1PkQJ4c/i72MMH3GxuVJ3vzQQfkHavzlqMjioxXkFeHFQxfwomi17MZI7OE3BD wbMDOADZCY2FR4jDwbuYd7CDlum9ndwCWgn1CJwDTz+YzyijaIVNykoXbAYbivL1F0hp BYHFVYqgtoQtYgoqUTgJ2unXotiM8oDKIAl1y9k0GVtnWgY4sd+A7iw4EWpVTQkMSyuR ENtkTC85Ywnw83nsXqhIAgQ3348qKInRIEhJR9/L8xybjLpDLLsjPU77/Cl4W84uoDMI 8rtLmDMi3AnQoPnFjkWyStkqwTyOHQzuo6U0LaAkmKsaKGNiYUd0Rk942s3U357eFzFH v0gw==
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=lkFncC2ejP5EBjl7iBudwspHQQVTqvvWC5ARDznQQAc=; b=ue2goD62IHycvZbOx2CaaoibDs6gbokfegsJ+VtvgmLV2W+umvtQDsJ1FCfbinFIJP hPdA6HQqGTw1j6xdHuH7JOKHfx2Z6b8WQ1DUJMm1HWEX0OpWm89XS+IeSvRKuTam7Twv yPRYdjuWxIQrRoWfX9ifgaYudZxnWKb92pOyr4D69XNgHo9cm70Mg0XsqZwtvc8xrhUM TGhdUmLbBwfW0Hk60G/2SvnlClmG0YHP7gcLlhe2X40evbbyirm0JTGqggyHAfRpTruU Z1W2dZ1eA6XmSJf2HQ/ZcVP1ogFhHM1ehapUw0Em/Tmw1aR0YGVT1xqgSBKF+5DdFObP NHtA==
X-Gm-Message-State: AGi0PuYVDf0rDBIJVaAjDBi8GvbeaahPvFHLk3fhmfyf0w6s88E/JrYv OubpxBASDveFQeMtQUqaoOQSCL7CWHLRFhzbL4Z0zbU=
X-Google-Smtp-Source: APiQypKwEw57yC3+NPa3g+M4XpVwUa8oV9voEZG0yUiKqOIPiCYjWM7ImLcR90KvQ9DkzOZQHEd8oXYa4rvn/DakVE0=
X-Received: by 2002:a05:620a:158a:: with SMTP id d10mr14870201qkk.259.1587368595586; Mon, 20 Apr 2020 00:43:15 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Apr 2020 03:43:14 -0400
From: Dominick Baier <dbaier@leastprivilege.com>
In-Reply-To: <452135A8-1B26-4815-9797-1D175431ADE6@pragmaticwebsecurity.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> <CAO7Ng+tJVsO4GZZNmNx2-nirWsjQcZxu0T9g4w_95vkPANSSmQ@mail.gmail.com> <452135A8-1B26-4815-9797-1D175431ADE6@pragmaticwebsecurity.com>
MIME-Version: 1.0
Date: Mon, 20 Apr 2020 03:43:14 -0400
Message-ID: <CAO7Ng+uXWdt8Dr2qzVB68YZdCX4jzm+332t6JRXdxNsDHe2zZA@mail.gmail.com>
To: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Cc: Vittorio Bertocci <vittorio=40auth0.com@dmarc.ietf.org>, Vladimir Dzhuvinov <vladimir@connect2id.com>, David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000044919605a3b40dd5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/aCGmbATLSdNIcAw4PCqF-A6yz6I>
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 07:43:19 -0000
Hence my question What should be the recommended semantics - “informative” - “or don’t accept before a certain time stamp” ? ——— Dominick Baier On 20. April 2020 at 09:05:53, Philippe De Ryck ( philippe@pragmaticwebsecurity.com) wrote: In theory, you can issue a token that only becomes valid in the future. That would have a different iat and nbf timestamp. I have not seen this in practice though. Given that RFC 7519 lists “iat” as informative, I would not change that behavior in a specific use case if there is no significant need to do so. Philippe On 20 Apr 2020, at 08:50, Dominick Baier <dbaier@leastprivilege.com> wrote: 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 <OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ 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
- [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) P… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Aaron Parecki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Brian Campbell
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Aaron Parecki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Brian Campbell
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… David Waite
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Philippe De Ryck
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… vittorio.bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… vittorio.bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… vittorio.bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Mike Jones
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Takahiko Kawasaki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Takahiko Kawasaki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Takahiko Kawasaki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Benjamin Kaduk
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Brian Campbell
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Benjamin Kaduk
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Benjamin Kaduk
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Jared Jennings
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Jared Jennings
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Manger, James
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Manger, James
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Hannes Tschofenig
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Hannes Tschofenig
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Phillip Hunt
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis