Why do ASP.NET Identity interfaces use strings for primary and foreign keys?

Question

I am looking at interfaces on new ASP.NET Identity classes and the database that it creates using Entity Framework Code First. I am using Visual Studio 2013 RC.

At first glance, the database schema looks pretty normal:

But all the keys: NVARCHAR (128)

And for some crazy reason, AspNetUserSecrets.Id is a PC that looks like it can point to multiple entries in the AspNetUsers table. Does this mean that multiple AspNetUsers will have to use the same password?

When I look at "Looking at the interfaces that you enforce, these are all the lines ...

 public class User : IUser { public string Id { get; set; } public string UserName { get; set; } } public class UserSecret : IUserSecret { public string UserName { get; set; } public string Secret { get; set; } } public class UserRole : IUserRole { public string UserId { get; set; } public string RoleId { get; set; } } public class UserClaim : IUserClaim { public string UserId { get; set; } public string ClaimType { get; set; } public string ClaimValue { get; set; } } public class UserManagement : IUserManagement { public string UserId { get; set; } public bool DisableSignIn { get; set; } public DateTime LastSignInTimeUtc { get; set; } } public class Tokens : IToken { public string Id { get; set; } public string Value { get; set; } public DateTime ValidUntilUtc { get; set; } } public class UserLogin : IUserLogin { public string UserId { get; set; } public string LoginProvider { get; set; } public string ProviderKey { get; set; } } public class Role : IRole { public string Id { get; set; } public string Name { get; set; } } 

So, I agree that I may have to implement this using strings for PK and FK relationships.

But I would really like to know WHY it is built like this ...?

EDIT: time has passed and now there are articles on how to extend the asp.net identifier to use int (or guid) fields:

http://www.asp.net/identity/overview/extensibility/change-primary-key-for-users-in-aspnet-identity

Answer 1

The goal was to allow both arbitrary types of identifiers (i.e. int , guid , string ), and to avoid serialization / casting problems for the id property.

So, you can define your keys as you like and just implement the interface method

 public class MyUser : IUser { public int Id { get; set; } string IUser.Id { get { return Id.ToString(); } } } 

Answer 2

Addendum to what Hao said:

• The Identity script prefers strings for a user identifier because we don’t want to properly serialize user identifiers (we use strings for claims for the same reason), for example. all (or most) Identity interfaces refer to a user identifier as a string.
• People who adjust the save level, for example. entity types can choose whatever type they want for keys, but then they themselves provide us with a string representation of the keys.
• By default, we use the GUID string representation for each new user, but this is only because it provides a very simple way to automatically create unique identifiers.

Answer 3

With ASP.NET Core, you have a very easy way to specify the data type that you want to use for Identity models.

The first step is to override the identity classes from <string> to <the data type you want>:

 public class ApplicationUser : IdentityUser<Guid> { } public class ApplicationRole : IdentityRole<Guid> { } 

Declare your database context using your classes and the data type you want:

 public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, Guid> { public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } protected override void OnModelCreating(ModelBuilder builder) { base.OnModelCreating(builder); // Customize the ASP.NET Identity model and override the defaults if needed. // For example, you can rename the ASP.NET Identity table names and more. // Add your customizations after calling base.OnModelCreating(builder); } } 

And in your startup class, declare an identity service using your models and declare the data type you want for primary keys:

 services.AddIdentity<ApplicationUser, ApplicationRole>() .AddEntityFrameworkStores<ApplicationDbContext, Guid>() .AddDefaultTokenProviders(); 

In ASP.NET authentication tables, the primary keys will still be in NVARCHAR, but in your application it will be the data type that you want. You can check this on the controller:

  [HttpGet] public async Task<IActionResult> Test() { ApplicationUser user = await _userManager.GetUserAsync(HttpContext.User); Guid userId = user.Id; // No cast from string, it a Guid data type throw new NotImplementedException(); }