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
