Duende.IdentityServer.Admin: a React admin panel for an identity server

One interface for clients, resources, users and audit

The project is a modern administration UI for Duende IdentityServer and ASP.NET Core Identity, and the description of its scope is worth reading as a work list rather than a marketing line.

You manage IdentityServer clients and resources, ASP.NET Core Identity users and roles, configuration health, auditing and security from one interface. Underneath, the stack is .NET 10 with Duende IdentityServer 8.0.9 on the server and React 19 with TypeScript, Tailwind CSS and shadcn/ui on the client.

The choice of Duende over IdentityServer4 is the strategic fact, and the 3.2 release makes it explicit. Version 3.2.0 moves the admin UI to React 19 and updates Duende IdentityServer to 8.0.9, described as a security fix for pushed authorization requests.

The client management workflow is the part that shows the most product thinking. There is a guided client creation wizard, and the client detail view shows only the tabs that the client's grant types make relevant rather than a fixed tab set for every client. The Integration tab then generates the .NET 10 setup code for the client you are currently editing, so the configuration snippet you copy is the one that matches what you just configured.

That is a meaningful improvement over a generic admin panel. The failure mode of identity server configuration is usually a mismatch between what the server expects and what the client sends, and generating the client side from the server side closes that loop.

Configuration rules turn drift into tracked issues

The monitoring area is the piece that goes beyond CRUD, and it is what separates this from a generic admin interface.

You define and track configuration rules for clients, API resources and identity resources. The rules flag deprecated OAuth 2.1 flows, enforce required scopes, validate naming conventions for clients, scopes and resources, detect client scopes that no longer exist, and warn about expired client secrets.

Each of those is a class of problem that identity servers accumulate silently. A client scope pointing at a scope that has been deleted does not throw an error at configuration time; it fails at token request time, in production, for one client. An expired client secret is the same. Naming conventions matter for a different reason, which is that a large identity server with inconsistent naming becomes hard to navigate and hard to review.

The documentation presents this as two screens, configuration rules and configuration issues, which suggests the model is a set of rules evaluated against the current configuration, producing findings. That is a different shape from a dashboard that only shows counts.

The security side of the same release adds hardened audit logging, stronger validation, and an optional FAPI 2.0 profile, and the quality coverage is described as expanded Playwright UI, Admin API, STS, repository and audit tests. The audit logging is not a bolt-on: an identity server audit log is the evidence you need when someone asks who granted which scope to which client.

Installing is a dotnet new template, not a clone

The installation path is a .NET template, which means you scaffold a project rather than fork a repository.

The template package is installed with:

dotnet new install Skoruba.Duende.IdentityServer.Admin.Templates::3.2.0

Then you create your own project from it, passing the identity and admin credentials as parameters:

dotnet new skoruba.duende.isadmin \
  --name MyProject \
  --title MyProject \
  --adminemail "[email protected]" \
  --adminpassword "Passw0rd-123" \
  --adminrole MyRole \
  --adminclientid MyClientId \
  --adminclientsecret MyClientSecret \
  --dockersupport true \
  --requirepushedauthorization true

The last two flags are the interesting ones, because they are decisions rather than names. dockersupport true generates the Docker support into the project, and requirepushedauthorization true turns on the pushed authorization request flow, which is the feature the 8.0.9 security fix relates to.

The prerequisites are the .NET 10 SDK, Node.js 22.12 or newer with npm for the React client, a database, either SQL Server with LocalDB by default or PostgreSQL, and Duende IdentityServer 8.0.9. The documentation warns that using older .NET versions can cause 502.5 errors on IIS or application startup failures, which is the sort of warning that saves an afternoon.

For local development the readme also points to a Docker path, and the compose file at the root shows what that looks like: an nginx proxy fronting the admin application and the identity server on the shared network, with hostnames for sts.skoruba.local, admin.skoruba.local and admin-api.skoruba.local, and the admin container configured entirely through environment variables using the standard double separator configuration syntax.

The upgrade from 3.0.0 needs new migrations

The 3.2.0 release carries a warning that is easy to skim past and expensive to ignore.

Upgrading from 3.0.0 requires new EF migrations, and 3.2.0 adds an index on the AuditLog table in a migration named AddAuditLogCreatedIndex. The CHANGELOG.md at the root carries the full list of changes, and the README directs you to the roadmap and changelog section for the release history.

The reason this is worth spelling out is the combination with the audit logging work. An index on AuditLog is only useful if the audit log is large enough to need one, which means the feature is intended for an identity server that is actually recording events at volume. A hardened audit log on a busy server can grow quickly, and a query without that index on the created column is the difference between a fast audit screen and a slow one.

There is a second migration note carried over from the older solution. The UserSecretsId for the Admin, Admin API and STS projects stays the same as in the Skoruba.IdentityServer4.Admin solution, to ease config migration, which means secrets left over from the old project on your machine will be reused. The documentation points out that ApplySeed could then point at your old database, and advises changing or clearing user secrets if you need isolation.

That is a helpful migration decision with a real trap in it. Anyone coming from the IdentityServer4 admin who assumes a fresh template means fresh secrets will find an old database seeded with an old administrator.

A large solution with deployment, shared code and template sources

The top-level layout shows how much sits behind the interface, and it is a much bigger repository than a single admin project would be.

There is src/ for the application, shared/ for the shared code, templates/ for the dotnet new template sources, tests/ for the test projects, build/ and deploy/ for the build and deployment configuration, and docs/ for the documentation. The solution file is Skoruba.Duende.IdentityServer.Admin.sln, and a Directory.Build.props and Directory.Build.targets pair centralises the build settings across the projects.

Docker is a first-class path rather than an afterthought. There is a docker-compose.yml, a docker-compose.override.yml for local overrides, and a docker-compose.dcproj project file, plus a .dockerignore. The compose file in the repository shows the shape of a deployment: the nginx proxy, the admin application built from a Dockerfile inside the admin project, and the identity server itself, with the database connection string supplied as an environment variable pointing at a db service.

The configuration surface is worth noting for anyone deploying this. The admin container takes its settings through environment variables in the standard environment variable form with double separators, covering the data protection database connection string, the authority pointing at the STS, the remote URL for the admin API, the base path, whether identity management is enabled, forwarded header handling, and the ASP.NET Core environment. The README also documents sections for STS configuration, admin UI configuration, identity mapping customization, external authentication providers, the email service, health checks, localization, and the API with Swagger, which tells you the feature list is longer than the highlights table.

The licence is Apache 2.0 with the LICENSE file at the root, the repository is not archived, the default branch is main, and the last push was on 2026-10-10.

Editorial conclusion

The Duende IdentityServer Admin suits a team running Duende IdentityServer who wants a working administration interface instead of editing configuration by hand or writing their own screens, especially with guided client creation and configuration rules that flag deprecated OAuth 2.1 flows. It does not suit a team on IdentityServer4, because this project targets Duende 8.0.9, and it does not suit a production install without reading the migration notes. Before upgrading from 3.0.0, plan for the new EF migrations and the AuditLog index, replace the seeded admin password, and review the template's default migrations before applying them to a database that matters.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. skoruba/Duende.IdentityServer.Admin on GitHub