The connection is in two parts. The first is IdentityDbContext<TUser>
, which the context that was scaffolded for you inherits from. It has the following properties:
public virtual IDbSet<IdentityRole> Roles { get; set; }
public virtual IDbSet<TUser> Users { get; set; }
This instructs Entity Framework to create tables for IdentityRole
and TUser
, which is a generic you fill in when you define your subclass of IdentityDbContext<>
. The default is ApplicationUser
. What isn't quite so obvious is that any classes related to these two come along for the ride and get their own tables as well, so we need to look at ApplicationUser
. However, ApplicationUser
is just what you add to it. It's your user, in the sense that it's whatever you make it. The real meat comes from the fact that it inherits from IdentityUser
, which is part two of the connection. IdentityUser
has the following navigation properties (relationships to other classes):
public virtual ICollection<IdentityUserClaim> Claims { get; }
public virtual ICollection<IdentityUserLogin> Logins { get; }
public virtual ICollection<IdentityUserRole> Roles { get; }
So between the two, you get tables for IdentityUser
, IdentityRole
, IdentityUserClaim
, IdentityUserLogin
, and IdentityUserRole
. There's your five tables. But, you are probably asking, those aren't the table names. Why is that? Well, that's Microsoft, just customizing the generated table names for no good reason. Well, the reason is most likely because older versions of ASP.NET authentication schemes had table names in that style, so they just continued on that way. I suppose it's debatable whether that's a "good" reason or not.