In my previous work (ASP.NET webforms) I've used the HttpContext.Current.Session object to hold security-related user data for the current user session, e.g.
Session("userID") = 4525
Session("customerId") = 123
Session("importantValue") = "ABC"
Having learned quite a bit on WebAPI 2, I'm now starting to learn MVC. I am constantly reading that Session and/or HttpContext.Current should be avoided with MVC...
...but there's not a lot of clarity on simple alternative. Some people say use TempData while others cookies, but both come with downsides as well.
My application is database-heavy, so I want to avoid hitting the database to re-read these values for every request. In WebAPI2 there are bearer tokens that get serialized as cookies. Is the Identity token secure enough to hold this data and avoid user-tampering (if used over SSL)?
Man, I'm not sure where that "use TempData instead of sessions" idea came from, but I'd really like to track down the source and hit them with a blunt object. TempData is session. It uses the session store under the hood. The only difference is that data you put there only survives to the next request, while data placed in Session survives until the session expires. Otherwise, it's exactly the same thing.
That said, there's a lot of debate surrounding this issue and much of it is misguided, leading to only further confusion. The crux of the debate, though, is that sessions are pretty awful things. But, there's really no alternative if you need to add a concept of state.
See, HTTP as a protocol is stateless. Each request is a unique entity, unaffected by any other request before or since. Web API, since you mentioned it, doesn't use sessions because it's what's called "REST-compliant", as in it follows the guidelines of REST. And, REST, which itself is modeled after HTTP, is also stateless. However, this is real life, after all, and you still need to do things like authenticate requests. As a result, things like auth tokens and such are sent either in the request query string or body or via HTTP headers. I'd argue that this is still "sessions", as a traditional session works much the same way: you pass along some "token" with the request, your session id, and the server uses that to recognize you as the same client from a previous request.
So, really, when people argue about sessions, they're not so much arguing about the concept of a session, itself, but really how it's used/abused, even if even they don't realize that's what they're arguing about.
I've seen others argue the merits of using something like Redis or another NoSQL option instead of session, but there you're just arguing about session providers, not sessions.
Personally, I see nothing wrong with using Session in an MVC project, as long as you use it properly. It's great for creating state for things like authenticated users. It would be very annoying to have to login again every time you wanted to request a new page from a site. Other than that, though, I'd pretty much leave it alone. There's very few things that actually should be persisted across multiple requests.