There are two separate questions:
- Does authentication work with caching in MVC?
- Does Session work before authentication in the face of a cache (even for unauthenticated users, who still have a hopefully unique session)?
The answers, respectively, are yes and no. Authentication works fine with caching. Try it with the SQL or Domain membership providers; you'll see.
Caching, however, can run before the authentication module. (For bonus points: Why?) Authentication is called only if it specifically hooks the cache (as AuthorizeAttribute does). Because sessions are user-specific, there is no guarantee you'll have a session inside of AuthorizeCore.
More bonus points: How might this change if you specified varyByUser in your cache configuration?
Unfortunately, doing authentication right is hard, because doing any kind of security right is hard. Microsoft tries to make this easier with the membership provider API. I strongly recommend using that when implementing custom authentication. I also recommend using the built-in providers and extending them instead of rewriting them whenever possible.
One other point: The ASP.NET Session provider and the ASP.NET Membership provider are entirely separate. Different membership users can share (!) a session, and, yes, you can attack a site this way. It is never safe to put security-related info in a session. Security is hard.