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

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 <news@bucksch.org> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>