04. PART 2 IdentityServer4 ASP.NET Core Identity

You can find the project here.

If you got up to this point I congratulate you for being persistent. Most of the “hard” steps are pretty much done. We just need to create database migrations for ASP.NET Core Identity to create the database tables. I will help you to understand new identity tables, similar as we did with IdentityServer4 tables. In the next tutorial we will start with adding custom properties to the user to start extending the functionality.

Database code-first migration

In Visual Studio open Package Manager Console. First we need to add the migration for ASP.NET Core Identity database context (IdentityDbContext). Like so

Add-Migration InitialIdentityDbMigration -c IdentityDbContext -o Data/Migrations/AspNetIdentity/AspNetIdentityDb

This will add database migration “InitialIdentityDbMigration” to “Data/Migrations/AspNetIdentity” folder right next to the IdentityServer4 migrations for configuration and persisted grants. Let’s update the database structure with ASP.NET Core Identity tables. In Package Manager Console execute update database command like so

Update-Database -Context IdentityDbContext

That’s it! We previously successfully migrated all temporary in-memory configuration to the database, now we also migrated the user store. Wow. Take a moment and relax now. Moment gone. Let’s see new tables we got to play with.

PS. Feel free to delete the “ScaffoldingReadme.txt” file from the project root. This readme file was automatically added when we did the ASP.NET Core Identity scaffolding.

ASP.NET Core Identity tables

I used the MSSQL database in this example but it’s pretty much the same for PostgreSQL. Here is the list of tables that we have in the “IdentityServerQuickstart” database. Seven tables that start with the “AspNet” prefix are the ASP.NET Core Identity tables that hold user store (users, claims, roles, logins, and user tokens).

Let’s see the relationship between ASP.NET Core Identity tables in a diagram

  • “dbo.AspNetRoleClaims” table is holding claims assigned to a specific role.
  • “dbo.AspNetRoles” table is holding a list of roles. It is a lookup table of all possible roles that exist and can be assigned to a user.
  • “dbo.AspNetUserClaims” table is holding claims assigned to a user. A claim is different from a role because a claim is a key-value pair. You can have a role or not have a role. Claim also provides a value for a specified claim. In a way, it is like an optional property assigned to a user.
  • “dbo.AspNetUserLogins” table is connecting external users to local users. All users specified in “dbo.AspNetUsers” table are local users. Say you want to login with Google and you want to link your Google account with your local account. This table holds that link so once you are linked you don’t have to go through the linking process again.
  • “dbo.AspNetUserRoles” table is a many-to-many relationship table that connects users with assigned roles.
  • “dbo.AspNetUsers” table is holding users. All of the user properties like username, email, password are stored here. We can also add custom user properties here to extend the user.
  • “dbo.AspNetUserTokens” table is holding external authentication tokens. This table is also used for keeping TOTP authenticator keys and recovery codes for user.


We added migration for ASP.NET Core Identity, updated the database with new tables and learned about each table. I explained the rest of the tables (the non “AspNet” prefix tables) in my previous tutorial.

In my next tutorial we will start adding custom attributes to the user. “Hard” stuff is pretty much over, we are now off to customization and adding new features.

You can find the project here.


For direct assistance schedule a technical meeting with Ivan to talk about your requirements.
For a general overview of our services and a live demo schedule a meeting with Maja.