Configure IdentityServer with Entity Framework (OIDC Part 6)

Share on facebook
Share on google
Share on twitter
Share on linkedin

In this post, we are going to build upon our IdentityServer setup with ASP.NET Core Identity for user management by moving the previously hardcoded IdentityServer configuration data to the database. This enables dynamic change of how IdentityServer is configured instead of needed a rebuild of the server for every configuration change. For this, we are gonna use Entity Framework and are going to write a seed script that takes the Config.cs configuration data and populates the database with it. As in the last post, this post only requires changes to the authorization server – the client app and the resource API stay the same.

The OpenID connect with IdentityServer4 and Angular series

This series is learning you OpenID connect with Angular in these parts:

AuthorizationServer – Setup IdentityServer configuration management with Entity Framework

We are so fortunate that IdentityServer has a package on Nuget that gives us DbContexts, that we are using for creating the database for saving IdentityServer configuration data. We install the package on Nuget called:


The database is updated with:

dotnet ef migrations add InitConfigration -c ConfigurationDbContext -o Data/Migrations/IdentityServer/Configuration
dotnet ef migrations add InitPersistedGrant -c PersistedGrantDbContext -o Data/Migrations/IdentityServer/PersistedGrant

This is where we persist OpenID connect configuration data such as ApiResources, claims, Clients and Grants etc.

We are not gonna hardcode the configuration data anymore, so we will now delete the following middleware from the Startup.cs file in the AuthorizationServer project:

  • AddInMemoryPersistedGrants
  • AddInMemoryIdentityResources
  • AddInMemoryApiResources
  • AddInMemoryClients

Using the AddConfigurationStore middleware we are going to setup the Startup.cs as:

var migrationsAssembly = typeof (Startup).GetTypeInfo ().Assembly.GetName ().Name;
services.AddIdentityServer ()
    .AddDeveloperSigningCredential ()
    .AddAspNetIdentity<ApplicationUser> ()
    .AddConfigurationStore (options => {
        options.ConfigureDbContext = builder =>
            builder.UseSqlServer (Configuration.GetConnectionString ("DefaultConnection"),
                db => db.MigrationsAssembly (migrationsAssembly));
    .AddOperationalStore (options => {
        options.ConfigureDbContext = builder =>
            builder.UseSqlServer (Configuration.GetConnectionString ("DefaultConnection"),
                db => db.MigrationsAssembly (migrationsAssembly));

Here we are setting up an Configuration store with AddConfigurationStore and an OpertionalStore with AddOperationalStore. This works by only providing it with the SqlServer connection string and the migrationsassembly.

Notice that we need to provide the assemblyName for it to locate the migrations assembly. With this, we setup IdentityServer to lookup configuration data in the database.

The IdentityServer config data is now loaded from the Config.cs file into the database with a seed script:

public class SeedData {
    public static void EnsureSeedData (IServiceProvider serviceProvider) {
        Console.WriteLine ("Seeding database...");
        PerformMigrations (serviceProvider);

        EnsureSeedData (serviceProvider.GetRequiredService<ConfigurationDbContext> ());
        Console.WriteLine ("Done seeding database.");

    private static void PerformMigrations (IServiceProvider serviceProvider) {
        serviceProvider.GetRequiredService<ApplicationDbContext> ().Database.Migrate ();
        serviceProvider.GetRequiredService<ConfigurationDbContext> ().Database.Migrate ();
        serviceProvider.GetRequiredService<PersistedGrantDbContext> ().Database.Migrate ();

    private static void EnsureSeedData (ConfigurationDbContext context) {
        if (!context.Clients.Any ()) {
            Console.WriteLine ("Clients being populated");
            foreach (var client in Config.GetClients ().ToList ()) {
                context.Clients.Add (client.ToEntity ());
            context.SaveChanges ();
        } else {
            Console.WriteLine ("Clients already populated");

        if (!context.IdentityResources.Any ()) {
            Console.WriteLine ("IdentityResources being populated");
            foreach (var resource in Config.GetIdentityResources ().ToList ()) {
                context.IdentityResources.Add (resource.ToEntity ());
            context.SaveChanges ();
        } else {
            Console.WriteLine ("IdentityResources already populated");

        if (!context.ApiResources.Any ()) {
            Console.WriteLine ("ApiResources being populated");
            foreach (var resource in Config.GetApiResources ().ToList ()) {
                context.ApiResources.Add (resource.ToEntity ());
            context.SaveChanges ();
        } else {
            Console.WriteLine ("ApiResources already populated");

This seed script is called from program.cs with:

using (var scope = host.Services.CreateScope())
    var services = scope.ServiceProvider;


    catch (Exception ex)
        var logger = services.GetRequiredService<ILogger<Program>>();
        logger.LogError(ex, "An error occurred while migrating and seeding the database.");

and adds or updates the configuration data in the database when the AuthorizationServer is run.


If we run the authorization server seed script and look at the SQL server explorer, we can now see that we have created the following tables:

Running it all

As usual, we can select the AuthorizationServer, AppClient, and ResourceAPI and run them in Visual Studio. The app should run like before, except we can change configuration data dynamically now by changing the database tables containing the IdentityServer configuration data. On the first run we run our seed methods that run our migrations and seed our tables with the IdentityServer configuration data.

For example we can see our client now in the Clients table:

Wrapping up

In this post, we made the IdentityServer configuration dynamic by using the IdentityServer Entity Framework library to store OpenID connect configuration data in the database. This created new tables for storing the IdentityServer configuration data and we seeded these with a seed script, running upon start.

In the next post, we are going to implement the whole setup with Angular application in AppClient, using an implicit flow client on the Authorization server and being able to access authorized data from ResourceApi.

Do you want to become an Angular architect? Check out Angular Architect Accelerator.

Related Posts and Comments

Build a Course Platform with SPARTAN Stack

Build a Course Platform with the SPARTAN Stack​ Step by Step Guide giving you a full production ready setup with industry best practices. <p style=”text-align: center;”><b>Press for sound.</b><b></b></p> <h2>Here’s what’s inside…</h2> <p >Section 1</p> <h2>Designing the course portal (Figma)</h2> <p style=”text-align: left;”>We will cover the fundaments of designing a brand new site in Figma including

Read More »


Develop Real Projects With Industry Best Practices Join our community of expert developers and get the industry level best practices, step-by-step, from real projects. Hi, I’m Christian Lüdemann I’m a web developer from Denmark and the creator of this blog. You are here to learn how to code like the best companies and learn

Read More »

Debugging Angular apps (with Sentry) and workflow

In this video, we cover the topic of debugging Angular apps and provide an overview of various tools and approaches that can be used. I highlight the use of Sentry as a tool for error logging and performance monitoring. I also cover my scientific approach to fixing hard-to-debug bugs. Do you want to become an

Read More »