5

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

IWriteApps
  • 973
  • 1
  • 13
  • 30
  • Are you sure that the claims number/size is the problem? It would surprise me. In that case you could use the small session cookies solution of WIF. It uses a local store for the claims and just a pointer/key/reference in the session cookie. – paullem Jun 19 '15 at 12:45

1 Answers1

5

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.

MvdD
  • 22,082
  • 8
  • 65
  • 93
  • Right but my question isn't so much related to the JWT itself as I can handle what claims are transferred via the scopes for the client. I'm just talking about user data like say "hometown" or pick anything off a facebook profile. I wonder if they have a profile table to store non-FK in a single record per user or if they have "hometown" added as an actual claim in a claims table. Or possibly both? – IWriteApps Jun 18 '15 at 19:04
  • I have no idea how FB does it. I would think they have something like a user table holding all user-related info, but other info (roles for example) would come from a different table. In ADFS, you can select per claim which attribute to query from AD or what query to execute against SQL. – MvdD Jun 18 '15 at 19:32