CODEWITHSUNDEEP
entity-frameworkdbcontextentity-framework-migrationsidentityserver4
Nicholas Ibarra
Nicholas Ibarra

Reputation: 504

IdentityServer4 PersistedGrantDbContext & ConfigurationDbContext

New to IdentityServer 4. I followed the IdentityServer4 EntityFramework sample here on the documentation.

After the migration script is run

dotnet ef migrations add InitialIdentityServerPersistedGrantDbMigration -c PersistedGrantDbContext -o Data/Migrations/IdentityServer/PersistedGrantDb
dotnet ef migrations add InitialIdentityServerConfigurationDbMigration -c ConfigurationDbContext -o Data/Migrations/IdentityServer/ConfigurationDb

It works and now my application has 3 DB Contexts.

My question is what are the two DB contexts for? What is the difference between the application db context and the other two?

If I update or add any models, do I need to update all three? Or when should I run a migration on the ApplicationDbContext and when to run on the other two.

Any insight or literature on these is appreciated. Thanks.

Upvotes: 13

Views: 8370

Answers (1)

Nicholas Ibarra
Nicholas Ibarra

Reputation: 504

Figured it out. Leaving this for anyone confused about this as I was.

There are 3 DB contexts and, as @Jasen mentioned, it is to split up access to the entities, or tables.

IdeneityServer4 + EntityFramework + ASP.NET Identity creates the following tables in the database:

SQL Server Tables

The contexts are used to reference the following:

ApplicationDbContext - responsible for users involved with ASP.NET Identity so tables

  • dbo.AspNetRoleClaims
  • dbo.AspNetRoles
  • dbo.AspNetUserClaims
  • dbo.AspNetUserLogins
  • dbo.AspNetUserRoles
  • dbo.AspNetUsers
  • dbo.AspNetUserTokens

PersistedGrantDbContext - responsible for storing consent, authorization codes, refresh tokens, and reference tokens

  • dbo.PersistedGrants

ConfigurationDbContext - responsible for everything else remaining in the database

So in regards to migrations, if I update any of the AspNet Identity models (i.e. ApplicationUser) then I would run the migration on the ApplicationDbContext. Any client tables or other scopes would be run on the ConfigurationDbContext. And to access the entites (or tables) would be the corresponding context.

Upvotes: 22

Related Questions