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".
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.