The NonceManager.verify() method implicitly assumes the oauth_timestamp is in seconds as it multiples the inputted value by 1,000 as soon as it comes in, but the JavaDoc does not reflect this. We discovered that if the client sends oauth_timestamps in milliseconds, the underlying SortedMap tsToKeyNoncePairs will grow without bound (for 44,000 years), with the gc() never finding any elements to evict because all values are in the future. This eventually leads to OutOfMemory heap error, causing our server to crash.
From Section 8 of the OAuth 1.0 specification: "Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests."
The specification suggests that, although oauth_timestamp is commonly expected to be in seconds, the Service Provider may choose a different time unit, such as milliseconds. There's no clear indication in the Jersey library, though, that using milliseconds will have a disastrous effect. At the very least, the documentation for Jersey should be updated to explicitly state that the timestamp must be in seconds.
Regardless of whether Jersey should support seconds or milliseconds for oauth_timestamp values, Jersey should be patched to prevent an incorrect or malicious client from causing the server to run out of memory. There should be a map based on System.currentTimeMillis(), rather than oauth_timestamp, that the gc() should use to evict elements from the tsToKeyNoncePairs map, so that it cannot trigger a memory leak, regardless of which clients connect to it.