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 <n...@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
