ProAuth 3.0.0 Is Available

ProAuth 3.0.0 is available today, 2026-07-08.

This is a major platform release, not a maintenance patch. Compared to ProAuth 2.2.12, which focused on Helm v4 compatibility and security maintenance, ProAuth 3.0.0 expands the platform across security standards, APIs, authentication views, user-store authentication, database support, and deployment operations.

That is useful progress, but it also means the upgrade needs planning. ProAuth 3.0.0 includes breaking changes and requires a planned maintenance window for existing 2.x installations.

flowchart TD
    Release["ProAuth 3.0.0"]

    Release --> Security["Stronger protocol controls"]
    Release --> APIs["API contract v2"]
    Release --> AuthViews["Fluid auth views"]
    Release --> UserStore["User authentication"]
    Release --> DataOps["Deployment baseline"]

    Security --> S1["PAR, JAR, DPoP, mTLS, FAPI, token protection"]
    APIs --> A1["Management API v2 and User Store API v2"]
    AuthViews --> V1["Razor custom views move to Fluid templates"]
    UserStore --> U1["Passkeys and account-management hardening"]
    DataOps --> D1["EF Core migrations, PostgreSQL option, Helm changes"]

    classDef release fill:#001847,stroke:#001847,color:#FFFFFF
    classDef pillar fill:#DCE8FF,stroke:#0041C8,color:#111827
    classDef detail fill:#FFFFFF,stroke:#CBD5E1,color:#111827
    class Release release
    class Security,APIs,AuthViews,UserStore,DataOps pillar
    class S1,A1,V1,U1,D1 detail

What changed in v3

The security work is the largest visible shift. ProAuth 3 adds support for hardened OAuth and OpenID Connect patterns such as Pushed Authorization Requests, JWT-secured authorization requests, DPoP token binding, mutual TLS client authentication and certificate-bound access tokens, JWT-based client authentication, and opt-in FAPI 2.0 Security Profile enforcement. The release also adds issuer response support for mix-up protection and broader token-protection options, including reference tokens, encrypted tokens, and JWT introspection responses.

The API surface also moves forward. ProAuth 3 introduces Management API v2 and User Store API v2 under /api/management/v2/ and /api/userstore/v2/. The v2 APIs use command-style write operations, type-safe patch commands, dedicated relationship endpoints, typed identifiers in the .NET clients, and a new RBAC permission model for administration. Existing v1 APIs continue to function in ProAuth 3.x, but they are deprecated and should not be the target for new integrations.

Authentication views have changed more deeply than their appearance. ProAuth 3 replaces Razor custom views with Fluid templates, moves authentication flow state server-side, and uses a Tailwind-based default view system with CSS custom properties for branding. Existing .cshtml custom views are archived during migration so they can be referenced, but they are not rendered by the new Fluid view engine.

For UserStore identity providers, v3 adds passkey-based authentication for sign-in and MFA scenarios. The passkey configuration is tied to the relying-party domain derived from BaseServiceSettings:HostUrl, so teams should treat hostname decisions as part of the security design before users register passkeys.

The platform layer changes as well. ProAuth 3 supports SQL Server and PostgreSQL for v3 deployments, stores ProAuth and UserStore objects in dedicated schemas, and uses EF Core migrations instead of the previous SSDT or DACPAC deployment model. Helm chart secrets, resource names, labels, and grouped configuration keys have also changed.

What requires action

Existing 2.x customers should treat this as a planned maintenance upgrade.

The migration guide is explicit: before upgrading an existing installation, move to the latest ProAuth 2.x release, take verified backups of the ProAuth database and every UserStore database, stop ProAuth 2.x or otherwise block writes, run the v2-to-v3 bridge migration with the ProAuth 3.x CLI, and then deploy ProAuth 3.x. A short downtime is required because the database schemas move to the ProAuth 3 layout before the application upgrade is completed.

Several other changes need review before the maintenance window:

Custom authentication views must be rewritten from Razor .cshtml templates to Fluid .liquid templates.
Custom CSS that depends on Bootstrap classes must be updated for the new view system and CSS custom properties.
CLI YAML files must be migrated to the new API-versioned resource format before reuse.
Customer-maintained settings, scripts, imports, and v2 API consumers must move from legacy TwoFactor and SecondFactor naming to Mfa and MfaFactor naming where the v3-facing surface applies.
Helm secrets, resource names, labels, selectors, dashboards, monitoring rules, and automation that reference old chart conventions must be updated.
API integrations should plan their move to v2, even though v1 continues to run during the ProAuth 3.x release series.
Client application key material for features such as private_key_jwt, JAR request-object signing, self_signed_tls_client_auth, and token encryption should be modeled through ClientAppKeySet resources.

There is one important database boundary to call out clearly: the standard v2-to-v3 bridge migration supports SQL Server source and SQL Server target databases. Direct migration from SQL Server 2.x databases to PostgreSQL 3.x databases is not part of that standard upgrade path. PostgreSQL is available for fresh ProAuth 3.x installations or for a separate customer-specific data migration project.

AdminApp in this release

ProAuth 3.0.0 continues to ship the current AdminApp UI for this release cycle. It has been updated to operate against the new API landscape and current runtime and dependency baselines. The redesigned Admin UI is not part of 3.0.0 and is planned for a later release.

That matters operationally: administrators do not need to plan a full UI changeover as part of the 3.0.0 upgrade, but API alignment and Helm secret changes still affect the AdminApp deployment.

How to plan the upgrade

Start with inventory rather than configuration changes. Identify custom views, custom assets, CLI import files, API integrations, Helm secrets, Kubernetes selectors, monitoring rules, database topology, UserStore databases, and any automation that names ProAuth resources directly.

Then rehearse the path outside production. The database migration, view migration, YAML migration, API client migration, and Helm chart migration are related but separate pieces of work. Keeping them separate during rehearsal makes the production maintenance window easier to reason about.

The full source of truth is the ProAuth 3.0.0 release notes and the ProAuth 2.x to 3.x migration guide. Use those documents for the exact steps and mapping tables before scheduling the upgrade.