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

Ben Bucksch <news@bucksch.org> Fri, 22 January 2016 00:03 UTC

Return-Path: <news@bucksch.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CC14E1B3522 for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 16:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 281-20PbmY9T for <oauth@ietfa.amsl.com>; Thu, 21 Jan 2016 16:03:50 -0800 (PST)
Received: from mail.server.beonex.com (mail.server.beonex.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3FD1B3524 for <oauth@ietf.org>; Thu, 21 Jan 2016 16:03:49 -0800 (PST)
To: oauth@ietf.org
From: Ben Bucksch <news@bucksch.org>
Organization: Me, myself and I
Message-ID: <56A171E9.6060705@bucksch.org>
Date: Fri, 22 Jan 2016 01:03:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0a1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/yuaCXyUs8nG-mqdBPcDxD2-jdAk>
X-Mailman-Approved-At: Fri, 22 Jan 2016 06:50:48 -0800
Subject: [OAUTH-WG] JWT compares client time with server time
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 22 Jan 2016 00:05:18 -0000

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 

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.