You can "probably" get away with 64 bits and modest rate limiting?! At 1 million requests a second, that's half a million years to try every possibility. So 250k years for a 50% chance of guessing a random 64 bit token. 64 bits is a lot!

And very few web apps can handle a million requests per second.

Two points:

Your calculations assume that attackers are interested in brute forcing one particular token. But if your app issues a lot of tokens then it becomes easier for an attacker to find some valid token.

For example, if you issue a billion tokens and allow a thousand requests per second then I can find one of those tokens in about 100 days. Is that realistic? Maybe not, but it’s a lot lower than 250k years.

The second point is that I’ve several times in my life seen code that logs a hash of a security token to allow easy correlation of requests. Such a hashed log is then vulnerable to offline brute force attacks with very many more than a million guesses per second.

The first point is what was in the post as being tied to the resource.

Don't pass tokens to /me, instead to /user/name that way having a valid token is only half the solution.

(Author of the post here).

My point is that you can easily make this a complete non-issue by increasing the entropy of the token. 96-bit tokens are 16 characters in base64url - just 3 more characters than the 64-bit tokens used by Waterken, yet with a token space 4 billion times as large. By way of contrast, Google Docs URLs include a random string that is over 40 characters long.