Assuming I generate random bytes with a secure PRNG, how many bytes do I need to make authorization tokens secure?
Specifically, when users log in to a website, a token will be generated and stored in a cookie to authorize future requests. Server-side, the token will be stored in a database and looked up when a request is received.
Since authorization tokens are random, your primary attack vector is brute-force guessing.
In an online attack, your defense strategy may limit the guess rate or total allowed guesses and therefore limit the necessary bit length.
An offline attack is more interesting, if such an attack is possible in your environment. With today's technology, 64 bits (between 10 and 11 characters alphanumeric) is just at the edge of guessable given a fair amount of time and a silly amount of money. On the other hand, 128 bits (between 21 and 22 characters alphanumeric) is beyond the reach of brute-force attacks pretty much indefinitely unless our understanding of time thermodynamics drastically changes.
Secure against what?
Though actually you don't have to worry about answering that, as for any plausible concern, @terry-chia's answer of 16 bytes will be sufficient.
If you need to defend against accidental collision (two users being issued the same token) then you need to look at how many distinct users you could ever have and do a bit of math. So if your tokens are used for identification (like as a username) as well as for authentication, then you need to worry about these sorts of collisions.
Still, I'm guessing that there is no chance of your number of users reaching beyond the trillions, so even if you do use these tokens for identification, 16 bytes will be enough.
At about 8*10^14 users, you will have about a 1 in one billion, 10^{-9}, chance of there being at least one pair of users ending up with the same token. If that is too large a risk, then go with 20 bytes. The math for this is can be found under descriptions of the Birthday Problem
