choose between asp identity claims and sessions data
J

2

11

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.

Juliannjulianna answered 5/2, 2016 at 18:31 Comment(2)
Session blocks concurrent ajax requests while identity doesn't.Dreibund
This changed in asp.net core, which doesn't use locks. However, for asynchronous loading of session LoadAsync() must be called prior to accessing the session values. learn.microsoft.com/en-us/aspnet/core/fundamentals/…Eno
L
5

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 )

Lhary answered 20/4, 2017 at 21:1 Comment(0)
C
6

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.

Cambric answered 8/2, 2016 at 11:30 Comment(5)
Thank you for your response. However, I have read through the link but it does not answer my question. I already know about claims. I use claims in my projects but I also know that those user-specific properties stored as claims can as well be stored in session and in both cases save round trips to database. But, my question is to clarify which approach is better in terms of best practices and performance*. **The link you posted does not answer this question.Juliannjulianna
I will try to explain bit more. See the updated answerCambric
I perfectly understand the concept you are explaining though I would love lo commend your great explanation skills. But, that is not the area I am having confusion. What I need to be clarified is thus: what is the difference in storing that username as new Claim(ClaimTypes.UserName,"username"); and storing it as Session[UserName]="username" considering best practices and application performance?Juliannjulianna
Sorry, I think I still don't get your question clearly. Where do you store the claim new Claim(ClaimTypes.UserName,"username"); ? In general I think Session[userName] = "username" is not a best practice.Cambric
I'm with Uche Ndukwe. Your answer is not clear at all. You can store data from a user using CLAIMS or using SESSION. What's the best approach and why?Antons
L
5

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 )

Lhary answered 20/4, 2017 at 21:1 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.