Re: [OAUTH-WG] JWT compares client time with server time

Thomas Broyer <> Fri, 22 January 2016 16:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07AE21AD289 for <>; Fri, 22 Jan 2016 08:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YtQtT_KI-fBQ for <>; Fri, 22 Jan 2016 08:05:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9173A1AD277 for <>; Fri, 22 Jan 2016 08:05:20 -0800 (PST)
Received: by with SMTP id x4so44085318lbm.0 for <>; Fri, 22 Jan 2016 08:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=fsQuwy0V839A5AhYf/Cq9cboIewbAbMN16JJWYEiWIQ=; b=G44wRu7CwtrWEDesKw1Vrnm6Zn2G+IrwJMb2AV+oVGzoDOEcjvQ+Sbix6hygIUpNu/ Cr9WGMuITlLJZxGI+bhVZTSKf/bino9VX3VNcOMqK/v7/dFYw2RRD8utvLvFG4SZ02rQ A1qCJU1OPeR+Bc9hSsM6wwbtdSSDLZ0ByOaHpZY8iFtvdeUDvN97za9zkrkje4vfE7lg cb8/VnSr7e+C2+SpoMIdfmvTDOJucCQL65l+N0gR1SCTvBMHH2UvnyoWExVD17yL9yq4 RU7EUIdIOAuuFap4eVidRiSYAcRlA3HKSs6evWyN2LV0IMMNOv3TdM6yKrCAX/OKCHb9 KbHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=fsQuwy0V839A5AhYf/Cq9cboIewbAbMN16JJWYEiWIQ=; b=AD7ee4RGjMpgNrvYRk23km8jNZDwU3t6RJXC5nPfZIq7QmvfDdn4Bf7ivawDT8vsEs rJ2ye2BOcTiQt90Gh64Sz9GpWhCaRM58hKaor2NhFjmcoQrVL5ge0cn40Alews8LFp/w Gt5Pp6maSpUJvBD1rSi4pyBwdPZ1yROFb5cGS0wWcnjOMMA3cLACc9MMcQYaizz10iJK gTpDhn9NYsJV9Ty2K16u4yhnVVuMDrQPWknFcGscoad64QilgCyzw583YXVc7bgNytN+ LDu3zNpJVnAIOqxEmxMnFqUMmSRDbKGB0jESjvSNcNRTcTVwnWaHWmgrYtPMvHPkcgCJ T3vg==
X-Gm-Message-State: AG10YOT47X/2z2ZgACvutIRy0CT8BqmgNrly3ZKwMUR244jCOpf4q1Wd0xq0VQOGbsCgeX2Xz0H5UwRTYpygaw==
X-Received: by with SMTP id i2mr1502186lbj.107.1453478718750; Fri, 22 Jan 2016 08:05:18 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Thomas Broyer <>
Date: Fri, 22 Jan 2016 16:05:08 +0000
Message-ID: <>
To: Ben Bucksch <>,
Content-Type: multipart/alternative; boundary="001a11c36b66b84fb10529ee624f"
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT compares client time with server time
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2016 16:05:23 -0000

Or just account for clock differences when comparing values, which I
believe is what the specs suggest.

Le ven. 22 janv. 2016 15:50, Ben Bucksch <> a écrit :

> Story: We wrote a script implementing JWT.
> The code was working for my colleague, who wrote the script, but I just
> got "Invalid authentication credentials".
> We were debugging it for days (!), suspecting shell argument passing and
> parsing, OS differences and what not. We compared credentials and
> confirmed they are identical. Still, the result was different. During
> debugging, once, by coincidence, it worked - at a time when it should be
> expired.
> What was the reason? My clock on my computer was fast.
> I was speechless. Client/server protocols must NEVER compare client
> clocks with server clocks, because clocks are very often off. Even if it
> was originally set exactly right by the second, clocks always have a
> drift in one way or another. If you have 5 million users, you will
> surely have 500000 whose clocks are off by 1 minute, and 50000 users
> whose clocks are off more than that.
> In my case, my clock was 95 seconds fast. That's not uncommon. You
> cannot expect nor demand that every computer in the world runs NTP clients.
> OAuth 2.0 knows that and does not rely on client clock matching server
> clock. For good reason. Ditto HTTP Cache headers don't send client time,
> even though that's an obvious and simple implementation, but the server
> sends and ETag and the client echos it back. Even if that's a more
> complex implementation, it's crucial to work reliably.
> ------------------------------------------------------------------------
> Worse, in JWT, iat (time of issue, created by JWT client) is often
> enforced with second precision on the JWT server. A client clock that is
> just 3 seconds fast (very likely) will cause an iat in the future, which
> makes the server reject it.
> You simply cannot compare client clock with server clocks. Please change
> the protocol to not do that, or take JWT off the proposed standards track.
> _______________________________________________
> OAuth mailing list