In order to access resources in my web service application, client applications need to provide a shared secret unique for each resource.
Question is: Are Longs generated by a SecureRandom reasonably safe for this purpose (e.g. against brute force attacks)? Or should I use a UUID instead?
The web service runs over HTTPS and I can guarantee that no collision (with either Long or UUID) occurs. Question really only is whether the domain of a Long in Java is large enough to provide protection against exhaustive attacks over HTTPS.
The simple answer is that you can't EVER guarantee there won't be any collisions for a randomly generated number pair / sequence. All you can do is design things so that the probability of a collision is acceptably low for the application. How low that probability needs to be depends on the details of the application.
The thing that puzzles me about this is why a collision would be a problem with shared secrets at all. Are you really asking about the probability of someone guessing the shared secret?
OK, so this is a simple maths problem. Take the long example.
2^64 possible values of a long.V of these are "valid secrets".N guessed secrets per second.P that someone can guess one of your secrets in a given time interval T.Derive the formula, plug in the variables V, N and T, and decide whether P is acceptable.
Note that "a practically relevant chance" is not something we can advise you on. Rather you should be deciding what an acceptable risk ... based on an analysis of the costs / consequences of someone succeeding in breaking your scheme.