Table confilict while integrating Identity Server 4 and Entity Framework Core together

Question

I have generated a dotnet core project with the command “dotnet new angular …”. With individual account authentication option. The dotnet core has generated a project with application data context like the following.

public class ApplicationDbContext : ApiAuthorizationDbContext<ApplicationUser>
{
    public ApplicationDbContext(
        DbContextOptions<ApplicationDbContext> options,
        IOptions<OperationalStoreOptions> operationalStoreOptions) : base(options, operationalStoreOptions)
    {
    }

} I would like to integrated the identity server 4 into the same project and be served on the same instance of the api controllers. I have followed a guide linked below to store the configuration and operational store in the ef database. http://docs.identityserver.io/en/latest/reference/ef.html

I have found out, that the DeviceCodes and Persisted Grant table are already in place in the database. while I tried to migrate the database to meet the requirements of the Operational Store. I have looked into the ef source code, that the ApiAuthorizationDbContext class has already included the these tables to support Identity Server.

Now I am not quite sure which is the best solution (1) Should I switch the ApplicationDbContext to extend the IdentityDbContext instead of ApiAuthorizationDbContext and use completely the way described in the guide above? (2) Or should I skip the steps related to the OperationalStore DbContext and let the identity server 4 use the existing tables provisioned by the ApiAuthorizationDbContext? And how can I put them together? What is the best practice? Thank you very much in advance.

Answer 1

In my application I took the source-code for the IdentitServer4 entitframework core NuGet packages and added them to my IdentityServer project (in a separate class library).

By doing this I get in control of how it is implemented and also how/when apply the migrations. This makes it it easier to customize it as you like.

Then having separate contexts for IdentityServer and your application needs also gives you good separation of concerns.