Is there any difference between a GUID and a UUID?

Apparently not, Microsoft just hijacked the acronym GUID for themselves and created their own standard like they always do. See this question on StackOverflow: stackoverflow.com/questions/246930/is-there-any-d…

Quoting from this page:

4-byte value representing the seconds since the Unix epoch,
3-byte machine identifier,
2-byte process id, and
3-byte counter, starting with a random value.

This looks one effective way of generating UUIDs. Negligible (or no) duplicates, I guess.

Similar in a web2py discussion plenty of details there. See the current implementation

I would say that UUIDs are secure provided they are of "Version 4" and that they have been generated with a secure random number generator. If this is the case then it will address most of the security concerns. Also V4 UUIDs ensure 122 random bits out of total 128. So, the probability that an attacker guesses your token correctly is very less. Therefore, the bottom line is check how UUIDs are generated in your code and if they are of V4.

Let's start with Java, Java uses UUID version 4, let me quote wikipedia:

Version 4 UUIDs use a scheme relying only on random numbers. This algorithm sets the version number (4 bits) as well as two reserved bits. All other bits (the remaining 122 bits) are set using a random or pseudorandom data source. Version 4 UUIDs have the form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal digit and y is one of 8, 9, A, or B (e.g., f47ac10b-58cc-4372-a567-0e02b2c3d479).

If you have a look at the source code for how GUIDs are generated in Java, you'll see that it uses the SecureRandom function for the 122 random bits. Quoting the Java docs,

This class provides a cryptographically strong random number generator (RNG).

A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1. Additionally, SecureRandom must produce non-deterministic output. Therefore any seed material passed to a SecureRandom object must be unpredictable, and all SecureRandom output sequences must be cryptographically strong, as described in RFC 1750: Randomness Recommendations for Security.

So Java UUIDs seems to be random enough for one-time tokens.