Is there any benefit to storing user information in AspNetUserClaims with Asp.Net Identity 2?

Question

I would like to store some additional user information. From what I understand the following is the usual option:

public class ApplicationUser : IdentityUser {
        public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager) {
            // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType
            var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie);
            // Add custom user claims here
            return userIdentity;
        }
        public string FirstName { get; set; }
        public string LastName { get; set; }

    }

Here the FirstName and LastName have been added and they will appear as additional fields in the AspNetUsers table.

However it seems that now with Asp.Net Identity there's also an option to store this type of information in the AspNetUserClaims table.

Can someone explain to me. Going forward is this the kind of information that could be stored in AspNetUserClaims. If so then does anyone have any examples of this.

Answer 1

At the end of the day, your signed in user will be converted into a series of claims stored in the ClaimsIdentity representing your user in HttpContext.User.Identity. You can choose to store FirstName/LastName as columns in the user table which you then can explicitly read out and convert into the appropriate claims (if desired), or you can store them directly as claims in the AspnetUserClaims table (which is just stores them as two string columns) which by default will just automatically get added to your user's claims identity. Both methods are more or less equivalent though, so its up to personal preference.

BTW the only reason you would want these in the user's ClaimsIdentity at all, is if you wanted to save a db hit just to display the name, and always use the FirstName/LastName claims in the ClaimsIdentity. If you fetch the user, and use user.FirstName instead, there isn't much value in also generating the name claims.

Answer 2

In addition to @Hao Kung, when claims are going to be longer than allowed Cookie capacity of the browser, claims information could be trimmed.

According to Thinktecture Identity Server article, one of the famous alternative of default AspNet Identity, it said as below.

Once your application becomes complex, so are the number of claims to handle. By default, all the claims are stored as part of the session cookie and browsers like Safari impose a restriction on the size of the cookie. So one fine day, when you add few more claims to the application, you will start getting serialization errors. That's because only partial cookie will be sent back to the server and server does not know what to do with it. So the solution for this problem is to create the security token in "Reference" mode. What it means is to store the token on the server and just store a reference session id as the cookie. See the image below. The cookie size is just few bytes:

Answer 3

When saving information (a claim) in the ApplicationUser, every user will have a placeholder (a column in the DB) for this information, and you will be able to save 0 (null) or 1 value. Should a new type of information be required, you would need a new column.

On the other hand, saving information (a claim) in the AspNetUserClaims table means the information is saved only when it is needed, that you can have multiple claims of the same type and that you can add new claims at any time without touching the data model.

Examples:

Let's think of a claim is_top_1percent_of_whatever. If underlying data is saved in ApplicationUser, 99% of the users will have a null or false entry.

For a claim high_school_name, if it is saved in ApplicationUser you can record only 1 high school name... if the user went to 2 different schools, there is no way of record this information. If saved in AspNetUserClaims, you can record as many high school per user as needed.

Related to the previous example, let's say you spell out explicit claims like is_interested_in_sport, is_interested_in_camping. The day you want is_interested_in_fishing, you would have to change the DB model is stored in ApplicationUser or just add a record if stored in AspNetUserClaims. This is also true for persisting claims received from an external provider.