TheIdServer is an open-source identity and access management server for .NET teams that need to issue OpenID/Connect, OAuth2, WS-Federation and SAML 2.0 tokens from a single self-hosted system with a browser-based admin interface.

What it is

TheIdServer is an identity server written in C# for the .NET and ASP.NET Core ecosystem. It is built on two libraries: Duende IdentityServer, which implements the OpenID Connect and OAuth 2.0 protocols for ASP.NET Core applications, and ITFoxtec Identity SAML 2.0, which implements SAML-P for both the identity provider (IdP) and relying party (RP) roles. The project combines these into one deployable server that also ships an administration user interface, and it is released under the Apache-2.0 licence.

The concrete problem it solves is consolidating several federation protocols that would otherwise each require separate tooling. Applications on the web — browsers, mobile apps, web APIs and single-page applications — need to authenticate users and grant access to resources without exposing credentials to those applications, and different consumers speak different protocols: OpenID/Connect and OAuth2 for modern apps, WS-Federation and SAML 2.0 for enterprise federation. TheIdServer implements all Duende IdentityServer features plus a SAML 2.0 identity provider behind one admin interface, replacing the need to run a stack of independent sign-in servers to cover that protocol spread.

Key capabilities

• Implements every Duende IdentityServer feature, including OpenID/Connect and OAuth 2.0 token issuance, on top of the ASP.NET Core stack.
• Acts as a SAML 2.0 Identity Provider through ITFoxtec Identity SAML 2.0, supporting both IdP and relying party roles.
• Supports WS-Federation alongside OpenID/Connect, OAuth2 and SAML 2.0 from the same server.
• Ships an admin app built with Blazor WebAssembly for managing clients, users and identity configuration through a browser.
• Integrates key material with Azure Key Vault using the modern Azure.Security.KeyVault.Keys SDK, including DefaultAzureCredential support for Managed Identity and Azure CLI, with AzureKeyVaultTenantId required for Service Principal authentication.
• Publishes its documentation as a browsable HTML site generated from the repository's markdown, with dedicated pages such as doc/DATA_PROTECTION.md and doc/KEYS_ROTATION.md.
• Is built and published through CI, with an AppVeyor build, a SonarCloud quality gate, and Docker images produced by the docker.yml GitHub Actions workflow.

Who uses it and how

• Operators who want to evaluate the server quickly use the hosted in-memory instance on Heroku at theidserver-duende.herokuapp.com, which logs in with alice / Pass123$.
• Development teams deploying on their own infrastructure run it as a .NET application or as a container, pulling images from the aguafrommars ArtifactHub repository.
• Administrators who are migrating from the older Azure integration follow doc/DATA_PROTECTION.md and doc/KEYS_ROTATION.md to move existing encrypted data to the new Key Vault SDK, which the project states remains fully compatible.
• Projects needing enterprise federation use it as the single provider when some relying parties consume SAML 2.0 or WS-Federation while others consume OpenID/Connect.

Getting started

Run the project locally with the .NET SDK from the repository, or deploy it by pulling the published Docker image from the aguafrommars ArtifactHub repository; the same images are built automatically by the docker.yml workflow. For a zero-install look, the in-memory demo instance is available at theidserver-duende.herokuapp.com.

How it compares

TheIdServer does not offer itself as an alternative to Duende IdentityServer or ITFoxtec Identity SAML 2.0 — it is assembled from both, so it inherits their protocol coverage rather than competing with them. The project facts name no other comparable identity servers, so it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate the server itself: a persistent database backing users and configuration (the hosted demo deliberately runs an in-memory version), any Azure Key Vault used for data protection, and the container or host that runs it. It is a poor fit for teams that want a managed identity provider without running infrastructure, and for anyone needing a documented commercial support contract — the README leans on links to a separate documentation site and badges rather than self-contained setup instructions, so expect to read the external docs before deploying.

docker build -t aguacongas/theidserver.duende:dev -f "./src/Aguacongas.TheIdServer.Duende/Dockerfile" .
docker build -t aguacongas/theidserverapp:dev -f "./src/Aguacongas.TheIdServer.BlazorApp/Dockerfile" .