Is there any standard length of the token which should be used while generating the random tokens? Should we use the same standard which we use for generating Session IDs?
I would consider a 128 bits of entropy in a token to be the de-facto standard. OWASP and CWE both recommend this as a minimum. 20 characters of Base64 (capable of 120 bits) is also handy for something in the URL. I would also note that in many cases poor seeding for those tokens creates problems. For one bit of reference, see the (kind of tastelessly decorated, but very informative) slides from http://samy.pl/bh10/.
Make sure you choose your entropy source well.
This is an old question, but I've had occasion to look into this question and decided to at least look into what some and CSRF libraries use by default and my results are as follows:
Django : 32 random characters from the set [a-zA-Z0-9] : 190.53 bits of entropy
Ruby on Rails : 32 bytes of entropy (encoded as base64) : 256 bits of entropy
Spring Security : UUID4 (actually, this seems to use a PRNG, not an RNG, if I'm not mistaken) : 122 bits of entropy
OSASP PHP CSRF Guard (https://www.owasp.org/index.php/PHP_CSRF_Guard) : 128 characters from the set [a-z0-9] : 661.75 bits of entropy
OWASP J2EE CSRF Guard : 32 characters in the set [A-Z0-9] : 165.44 bits of entropy
Oracle ATG version 10.1.1 : a standard Java "long" encoded using ascii base 10: 64 bits of entropy
Note that my sample is heavily biased toward frameworks of which I can access the source code and frameworks I'm familiar with.
I've specifically tried to find frameworks which use 64 bits or less of entropy to try and justify why ATG would use a standard Java "long" and have been unsuccessful, so my conclusion is that 64 bits is probably too short.
That said, assuming an attacker can do 100,000 requests per second, it should take around 2.93 million years on average to brute force a 64-bit CSRF token. (And there shouldn't be more than one token in the whole token space, unlike with session id's.) So, maybe 64 bits is enough.
2 ^ 63 / (100,000 * 60 * 60 * 24 * 365) = 2.93 * 10 ^ 6
In CSRF an attacker can make many guesses. What if an employee visits an attackers site and then goes on Christmas vacation? An attacker could make many millions of cross-site requests. We have a similar concern for session id's. If either value is obtained then session is compromised. The same standards of strength should be applied to both CSRF tokens and Session IDs.
In both cases make sure the value expires. Can the attacker can't make 2^128 requests in a week, but eventually he will be able to. If your random number generator is weak, then you may think you have a 2^128th cryptographic nonce, but it might be much less.