PandaAuth: A Lightweight Self-Hosted Identity Service
A self-hosted OIDC identity service for .NET teams, built on OpenIddict with a core of one Server and PostgreSQL.
When designing sign-in for our own products, we wanted more direct control over identity data and authorization boundaries, along with a service suited to our .NET stack. We built PandaAuth and released it under the MIT license. It uses OpenIddict 7.7, .NET 10, and PostgreSQL. Community Preview 0.2.0-preview.1 is for early evaluation, carries no SLA, and is not the stable 1.0 release.
Architecture: protocol framework and identity application
PandaAuth’s identity-provider (IDP) core consists of one Server and PostgreSQL. OpenIddict handles OIDC and OAuth 2.0 protocol capabilities including authorization code + PKCE, client credentials, refresh tokens, userinfo, introspection, revocation, logout, discovery, and JWKS. Delegating standard protocol handling to a mature framework lets our implementation focus on identity application behavior and engineering boundaries.
PandaAuth owns the user and role model, EF Core persistence and database migrations, plus application capabilities such as sign-in, MFA, rate limiting, session governance, and audit. Clients can read discovery metadata and integrate with a standard OIDC client library; protocol integration does not require a proprietary SDK.
Lightweight describes the identity core, not a single-process product suite
“One Server” refers to the IDP core. The admin console (panda-auth-admin), account center (panda-auth-me), and .NET SDK (panda-auth-sdk) are companion components, all open source. The Quickstart Preview also starts PostgreSQL and Caddy locally so developers can try the authorization code + PKCE flow. It is for local evaluation, not a production deployment.
Security mechanisms need to be understood with their runtime boundaries
Passwords use Argon2id with OWASP baseline parameters. Sign-ins for unknown accounts and wrong passwords perform similarly costly verification to reduce account-enumeration risk from response-time differences. Five consecutive failed sign-ins trigger a temporary five-minute lockout.
Sign-in is rate limited by both IP address and account, covering distributed scans and repeated attempts against one account. Limiter state is process-local, so restarts reset it; multi-instance deployments also need to account for state boundaries between instances.
Security events such as password resets, account freezes, role changes, and MFA resets update account security state and revoke related tokens the server can identify. PandaAuth enables OpenIddict token-entry validation, so requests that check token status with the IDP can observe revocation. A downstream service that only verifies a JWT signature offline has no live revocation check and may continue accepting an issued access token until it expires. Each resource server owns its token cache and validation policy, which integrators should choose according to risk.
Signing-key rotation is checked at service startup, with a new key created when the rotation interval has elapsed. Encryption keys are created when absent and are not automatically rotated. Multi-instance deployments need a plan for key persistence, JWKS consistency, and rolling restarts; these are part of the deployment design.
Public integration and management boundaries
Application sign-in and authorization use standard OIDC / OAuth 2.0 interfaces; discovery metadata is authoritative for endpoint locations. Users and clients are managed through the admin console. The Management API is not currently offered as a public integration capability, so integrators should not depend on unpublished endpoints. Public documentation states that administrative changes and administrator sign-ins are audited, without recording plaintext passwords or verification codes.
Who should evaluate it
PandaAuth is for teams that want to self-host identity, work in .NET, and inspect or modify the server implementation. Its case against mature identity platforms is focused on stack fit, readable source, and a compact IDP core. Products differ in capabilities, operational work, and maturity, so compare them against your actual requirements. PandaAuth remains a Community Preview and is not intended to replace Keycloak, Authentik, Logto, or Casdoor.
Self-hosting also means owning production deployment, upgrades, backups, key protection, availability, and security response. If you are evaluating an identity system, start with PandaAuth’s product overview and integration docs, and confirm that the Preview stage and operating responsibilities fit your team.
Quickstart: local startup with authorization code + PKCE