choose between asp identity claims and sessions data

Question

I am trying to make a choice between storing user specific data in my MVC application either as identity claims or as session data to reduce the number and frequency of database round trips on requests. However, considering performance, security and other best practice considerations, I don't know which route to go.

I will appreciate any suggestions on this.

Answer 1

How you store user data for your app is very much dependent on the application itself. But as a guide, using claims-based authentication and store the claims in a session cookie is a very common approach. Have a look at asp.net identity - http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity

You should be able to optimize the data stored in the session cookie. For example: - if your application always needs to display the name of the user on every page you can have the name claim in the session cookie. But if you need to display other user information like address, company etc... in only one 'user profile' page, you can query those details in a database using 'nameidentifier' claim stored in the session cookie. If you look into the ASPNET-identity you will see that you will not need to work with session cookie directly as cookie authentication middleware make sure the claims are available via User property(or ClaimsPrinciple.Current) of MVC controller. You should decide what claims should be available to all requests via User property and What user properties should be queried through some userInformation database. Of course, you should store the key(nameidentifier or email) to userInformation database in the claims, So that you can query database anytime you wish.

Answer 2

IMO (and its just my opinion) based on what I know about claims, cookies and storage rules:

Performance wise I have never seen a difference between the Claims and Session storage (unless the cookie gets large from a LOT of claims) they both seem to be about the same performance hit as far as speed goes (they both have to go lookup the data from someplace (CLaims = cookie, session = server drive storage) as for best pratice that would fall along the lines of how MUCH data you need to store.

From what I have seen in my experience (correct me if I'm wrong) but Session data is stored on disk on the server and has basically only your servers hard drive free space for size limits etc whereas cookies do have a hard coded data size limit and the more claims you store the larger that cookie gets, so if you were say maxing out that cookie, the client may see a performance hit in the fact its sending the entire cookie data in every request to the site, where as with Session the server looks up the data locally and there is less data sent by the browser.

so my opinion of best practice is if your persisted data to save your database lookup is a small footprint then there really isn't a best practice to it just use whatever you prefer, BUT if your storing a lot of bits especially strings then session would be the best practice in my opinion as it saves data round trip between client/server and doesn't have the size limit that you may run into at some point and then pull your hair out wondering why your data isn't there (done this in the past myself because if the cookie is too large the client just silently refuses it and took 3 days to figure out it was the size of the cookie )