Search code examples
asp.net-mvcsession-cookiessession-stateclaims-based-identitycookie-session

choose between asp identity claims and sessions data


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.


Solution

  • 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 )