NIST provides good guidelines on the length of keys and hashes for various algorithms. But I don't see anything specifically on the length of a random or pseudo-random nonce (number used once).
If there is a single good answer for a variety of uses, I'd love to see that. But to make this concrete, I'll use the common "password reset via email" situation, in which the server generates a URL with a pseudo-random path component. It seems a bit similar to HTTP Digest Authentication, in which the example in the RFC seems to have 136 bits (dcd98b7102dd2f0e8b11d0f600bfb0c093).
I note that many folks seem to use version 4 UUIDs (which provide 122 pseudo-random bits) or this, as discussed at Are GUIDs safe for one-time tokens?, though the user has to beware the use of previous much-more-predictable UUID versions, and nasty persistent local attacks on the Windows random number generator which were mostly patched by 2008.
But ignoring the riskiness of getting tangled up in UUID versions and implementations, how many pseudo-random bits should be incorporated in the URL?