This is a great example of warning signs. Note the number of times sizes (bits) and algorithm (AES/Rijndael) are mentioned. Note the lack of clarity in the specification (is "+" addition, XOR, or concatenation?) Note the overly-large UID space which has nothing to do with security (will you really have more than 4 billion users?)
Now look at how useful this design is. You've created a single-purpose authenticator that just says "someone at some point in time has seen this exact UID/authenticator pair". All other features (expiration, privileges, source of the authenticator, version, system name the UID is for) are left out.
Our UID share a namespace w/ our note IDs, we don't see a reason to limit it to 4 billion objects (especially since the objects are versioned w/ revision IDs).
And your post, sire, is a great example of not understanding the intent of security. There's always a tradeoff between the requirement on the level of security and cost in implementing it. Security is a matter of tradeoff.
Even with your proposed solution, there are still security breach. How does your solution handle the situation where someone hijacks the user's machine and uses his browser session? How does your solution handle the case of keylogger stealing the user's userid/password and start a valid session?
See there are always ways to make any security solution fall short. The security is always a balance between a number of competing goals. If the solution satisfies the requirement, it's a sound solution.
Our userIds are 64-bit with a 128-bit secret.
We generate the authentication cookie as follows:
Rijandael(64-bit userId + 128-bit secret, 192-bit key) = 192-bits of cipher text
If you tamper with the cipher text the 128-bit secret won't be the same.
I don't see a practical cipher text tampering attack against this scheme.
There are authorization issues like how do expire a specific user login.