How long should a HMAC cryptographic key be? In the top answer to this question the answerer says 'with a sufficently long key'.

I am using a SHA1-HMAC (may switch to SHA256-HMAC) algorithm to verify cookies sent to clients as authentication tokens haven't been tampered with. The cryptographic keys are rotated with a new one being generated every 24 hours. Keys are valid for 3 days (i.e. there are 3 keys used to sign cookies active at any one time) meaning if a user doesn't login for 3 days then there authentication token is invalidated.

I am using 32 character long random alphanumeric strings as the cryptographic keys, would this be considered 'sufficiently long enough'?
Hashes and therefore HMAC do not take alphanumeric characters as input. You'd first have to convert the textual "key" into bits. I've put "key" in quotes because keys for HMAC should consist of bits in the first place.

The recommendation for HMAC is (indeed) that the key size is identical to the output size (and the intermediate state for Merkle–Damgård based hashes). Now lets presume that the characters in the key are completely random and that a large enough alphabet is used, say base 64. In that case you'd have 32 * 6 = 192 bits of randomness. That's larger than the required 160 bits of randomness.

If we'd use a single byte per character encoding such as ASCII or Windows-1252 then you'd get 32 bytes. This is much smaller than the ipad or opad used in HMAC. This means that additional hashing is not required before XOR'ing the key with ipad or opad. You would even be able to use UTF-16 as long as you don't use characters that require more than 2 bytes to encode. Anything longer than 64 bytes will require an additional hash calculation.





Below the security requirements for the key, taken from section 3 of RFC 2104:  HMAC: Keyed-Hashing for Message Authentication:


  The key for HMAC can be of any length (keys longer than B bytes are
     first hashed using H).  However, less than L bytes is strongly
     discouraged as it would decrease the security strength of the
     function.  Keys longer than L bytes are acceptable but the extra
     length would not significantly increase the function strength. (A
     longer key may be advisable if the randomness of the key is
     considered weak.)
  
  Keys need to be chosen at random (or using a cryptographically strong
     pseudo-random generator seeded with a random seed), and periodically
     refreshed.  (Current attacks do not indicate a specific recommended
     frequency for key changes as these attacks are practically
     infeasible.  However, periodic key refreshment is a fundamental
     security practice that helps against potential weaknesses of the
     function and keys, and limits the damage of an exposed key.)


Where H is of course the hash function, B the block size (64 bytes for SHA-1) and L the intermediate/output size (160 bits or 20 bytes).



Notes:


HMAC doesn't break in any terrible way if your key has somewhat less entropy; anything above 128 bits is probably OK.
Switching to SHA-256 is a good idea, even though it is not required to replace SHA-1 from a theoretical standpoint.