CODEWITHSUNDEEP
c#.netsecurityclaims-based-identityuser-profile
IWriteApps
IWriteApps

Reputation: 993

Should I store user data as claims or in a user profile table?

I'm working on a public facing system which will ideally grow to a large amount of traffic. This is all c# .net work.

I'm using claims-based identity and so I'm currently using a user claims table to store the user data, but as the user base grows I feel this will become too slow to support the traffic. I'm thinking of possibly creating a user profile table to store non-security related data horizontally as opposed to vertically as in a claims table, leaving just the security data in the claims table.

Is this a reasonable approach to the problem? Can anybody share some insight from experience they've had with a scenario like this?

Update

My question isn't regarding the size of the JWT token that's passed around with the users' identity. My question is regarding the strict use of a "UserClaim" table to store ALL of the user's data in Claim form as opposed to having a UserProfile or similar table to store certain things, as well as finding that right balance of "this data goes into the claims table vs this data goes into the profile table".

Upvotes: 5

Views: 2200

Answers (2)

Mosia Thabo
Mosia Thabo

Reputation: 4267

Sometimes asking these 2 questions will help you make better decisions:

  1. Is the user information provided by a third party authentication service?
  2. Are you going to be sharing the same info as a third part to the next consumer via your own authentication i.e JWT Service?

If you answer both of the above questions with Yes. then keep your user info in claims. Because you don't want to store same information twice (claims and table). External Authentications Services use claims extensively.

However, there's the other situation where you authenticate someone using a third party provider like google or facebook... And you want to use such information as part of user registration and you're basically using cookie authentication in your app. In this this case, I would advise on using a table. The reason for this is that, with claims, you will have to search a list of claims every time you need that firstName or lastName just to read their data... whilst, when on a table, the moment you request user row from table, those fields are there already... leading a better performance over claims. But often, performance is the last thing you want to worry about in this case... no one approach is better than the other, it all depends on your use case.

Upvotes: 0

MvdD
MvdD

Reputation: 23496

I would recommend to only keep data in the tokens that is used in authorization decisions and not bloat the token with user profile info.

Things like time-stamps between which the token is valid, the audience for which the token is intended, username, groups and roles for the user. See here for more info.

Keeping profile info in your token will force your application to get a new token if any of that info changes. Tokens are typically cached for their lifetime to prevent having to reissue them more often than needed.

Upvotes: 5

Related Questions