Extreme clock skew issues with token authentication

[mattheworiordan]

A customer has reported, that whilst using the Java 1.0.* library on a device with significant clock skew (more than 1 hour ahead), that after connecting to Ably, subsequent REST requests fail with 40105 error (nonce value replayed). The reason a 40105 is emitted because the customer is incorrectly using the same token request more than once, however this issue has highlighted a problem with the spec and clients with a significant clock skew.

The issues with the current spec are that:

• specifying queryTime true does not necessarily state that the client should obtain time independently of a create token request. As such, if the clock skew is greater than the TTL of the token it ends up with, the token is immediately considered expired the next time it is used.
• the spec assumes queryTime is explicitly set by developers who suspect a device is out of sync, which is a bit presumptuous given it's hard for them to know if a device's clock can be trusted or not. I think that instead of explicitly requesting that a client lib uses queryTime: true, why doesn't the library automatically update the time the first time it obtains a token, connects to Ably, or perhaps even issues any REST request. We could include the server time in any response perhaps when a param such as ?time-header=true is appended.

┆Issue is synchronized with this Jira Task by Unito

[mattheworiordan]

See https://app.intercom.io/a/apps/ua39m1ld/inbox/inbox/conversation/20863681656 for internal conversation relating to the issue

[SimonWoolf]

if the clock skew is greater than the TTL of the token it ends up with, the token is immediately considered expired the next time it is used.

Good point. Luckily there's an easy fix, since the token contains an issued timestamp, which it can use to set the server time offset.

(We should probably only do that if the library has obtained a token directly from ably using a token request though -- if we get a token from an authCallback/authUrl we can't be sure of how fresh it is. In that case we can always just not apply the expired logic. If a token is expired, Ably will tell the client which discards the token. That already happens, checking expired is just an optimisation).

the spec assumes queryTime is explicitly set by developers who suspect a device is out of sync, which is a bit presumptuous given it's hard for them to know if a device's clock can be trusted or not.

It's more that it assumes that device time is irrelevant and only auth server time (i.e. the lib that's generating a token request) matters. Which as you point out is wrong if the time is too off because of the expired issue, but per previous paragraph that has its own fix -- apart from that it's basically right. (And if their auth server is out of sync, they'll definitely know about it since every token request generated by that auth server will be invalid..)

why doesn't the library automatically update the time the first time it obtains a token, connects to Ably, or perhaps even issues any REST request.

An auth server that's just generating token requests might well go its entire life without ever actually obtaining a token, connecting to ably, or issuing any rest requests. So that may well not do anything.

If we're worried that there are too many auth servers with bad clocks, we could always just make queryTime: true the default. (We could then maybe do the ?tmie-header=true thing as well, just as an optimisation if you happen to do a rest request before creating a token request -- at least that way you don't have a library that works differently depending on whether you happen to be doing REST stuff with it as well as creating token requests)

[tomczoink]

@mattheworiordan is this issue considered resolved now?

[sync-by-unito[bot]]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2803