Sessions in ASP.NET MVC

Question

I'm quite new to MVC and recently I wanted to create a Login Form from an empty MVC template. I've heard about Identity class and Sessions. What is the difference between these 2? Should they be used simultaneously or are these different kind of things ?

Answer 1

There's a lot going on in this relatively simple question. First, I think you need to understand what sessions are.

The HTTP protocol is stateless. That means each request is its own thing, unaffected by anything that's happened previously. However, applications need state, so the concept of sessions were introduced. A session is combination of two components, one server-side and one client-side. In the traditional sense, the server will store some bit of data combined with a session id. It will then send a cookie down to the client containing that session id. The client sends the cookie back on the next request it makes. When the server sees the cookie, it uses the session id it contains to look up the data it previously stored.

When it comes to something like authentication, state is required to persist that authentication between requests. In something like an MVC site, sessions are used for this purpose. A cookie is set on the client, which is then sent back by the client with each request. The server reads the cookie, validates the authentication, and authorizes the user. In something like a Web Api, sessions are not allowed, so the authentication must be passed by the client with each request, usually in the form of a Authorization header, which will include something like a bearer token. However, any traditional web site that would be loaded by an average user via a web browser will persist authentication via sessions.

Now, within ASP.NET code, there's a static dynamic dictionary called Session . This utilizes the concept of sessions to persist state between web requests, but is not used by any of the authentication mechanisms available to ASP.NET sites. Use of Session is discouraged, because usually it would be more appropriate to persist data you would attempt to store there in a better place like a database. There's certain areas where using Session would be fine, but you should have a really good reason for doing so. However, again, none of this has anything to do with authentication/authorization.

Finally, ASP.NET sites have a number of different authentication systems available, some deprecated. In terms of traditional user authentication, you have ASP.NET Membership and Identity. Identity is newer and is preferred over ASP.NET Membership (also known as FormsAuthentication). However, it is only available to websites using MVC 5 or Core.

Long and short, if you're creating a new website today that needs authentication, you need to look into ASP.NET Identity. There's tons of examples and tutorials from Microsoft . You may or may not need to use Session in your application, but you should avoid using it as much as possible. Regardless, it's totally separate from authentication/authorization, even though, under the hood, they both utilize similar principles.