Your question doesn't give enough information about exactly what you want to do to know if this might work in your case. The most important answer is simple though: "don't do that; use a web framework instead". Session management should almost always be done in the standard way of your framework; then you won't have to do anything other than check if your framework thinks your user is authenticated.
Let's now look at the specifics of the code. You have used a cryptographic PRNG. That should be fine. You used 32 bytes = 256 bits of random data. This should be no problem (128 bits is normally enough against brute force attack; 256 is overkill, which is likely good in this case) your main fears should probably be seeding and leaking bits.
Seeding: the PRNG documentation says that if you don't give a random seed the PRNG will be unseeded. In real life it seems that it actually does get seeded from /dev/random. I deeply don't like this and would probably seed it explicitly. Better would be discuss with the author and send a patch to the documentation for the library so that it promises to do what it actually does. I don't have an OS without /dev/random to test on, but I think your function simply won't work there (which is good because it's safe).
Leaking bits1: If the attacker can find a situation where response time depends on the contents there might be a problem (e.g. force regeneration of the session). Looking up about timing attacks on Ironclad I don't think it's resistant (see e.g. https://firstname.lastname@example.org/msg00977.html). You need to check or protect against this. If the contents of the message are true then you should probably switch to a better library such as LibreSSL when it comes out (possibly GNU TLS?). If someone attempts to use the function on e.g. Windows I would simply exit with a warning.
Leaking bits2: your output is constant size but includes some special characters. If the attacker can find a situation where your message length depends on the authentication token then you have a problem. Using Base64 encoding (a second time) should be fine. Using maximal HTML encoding for your tokens will not be (n.b. normal HTML would be fine; but some encoders go too far).
Summary: probably your function is basically the same one used in many frameworks. Because of the risk of timing attacks and bit leakage I wouldn't personally want to release it for public use until I understood the whole surrounding situation of usage much better than I currently do.
(edited lots since I misread bytes as bits in the first response)