ProAuth 3.2.0

ProAuth 3.2.0 expands enterprise passkey and passwordless authentication, strengthens UserStore security and account lifecycle management, and improves OpenID Connect interoperability and client security. Administrators gain granular policy controls, governed recovery and identity workflows, and explicit claim-disclosure settings. This release includes breaking changes and coordinated migration requirements that must be reviewed before deployment.

BREAKING CHANGE

EdDSA/Ed25519 passkeys are no longer supported. Existing passkeys using this algorithm stop working after the upgrade and must be removed and registered again. Before upgrading, ensure affected users have another login, recovery, or administrative account-access method available to register a replacement. Passkeys using other supported algorithms, such as ES256, are unaffected. (#2941)

ACTION REQUIRED

Review the trusted context and claim disclosure upgrade guide and client authentication and grant security migration guide before deployment. Apply the database migrations, coordinate the rollout across all instances, update affected BFF clients, and plan for application reauthorization and user reauthentication. Follow the deployment requirements below; mixed runtime versions do not provide consistent claim-disclosure behavior, and older binaries cannot read the compact FIDO metadata snapshot. (#2941) (#2944)

Core

Core

Enterprise passkey and passwordless policies

Administrators can now govern passkey enrollment, use, recovery, and lifecycle independently for each UserStore identity provider instance. Policies support environments ranging from consumer applications offering passkeys alongside passwords to regulated deployments requiring attested, hardware-bound credentials and independent administrative approval. (#2942)

Four recommendations provide secure starting configurations: (#2942)

• Passkey coexistence adds passkeys while retaining passwords. (#2942)
• Consumer passkey-first encourages adoption and allows users to remove passwords once recovery requirements are satisfied. (#2942)
• Enterprise passwordless supports managed password removal, multiple credentials, recovery codes, and temporary access passes. (#2942)
• Regulated hardware-bound requires strongly attested device-bound credentials, credential diversity, enhanced recovery controls, FIDO metadata, risk evaluation, and maker-checker approval. (#2942)

Applying a recommendation writes ordinary UserStore IDP options rather than locking the identity provider into a fixed product mode. Administrators can review and adjust the resulting settings to meet their security and usability requirements. (#2942)

New capabilities include: (#2942)

• Credential compliance, maturation, diversity, risk, and attestation controls. (#2942)
• Controlled password removal with readiness checks and durable notifications. (#2942)
• Security contacts, recovery codes, temporary access passes, and identity reproofing. (#2942)
• Restricted enrollment and recovery sessions. (#2942)
• Per-user credential investigation and compromise response. (#2942)
• Central security operations for approvals, recovery, migrations, and audit history. (#2942)
• DNS-verified relying-party ID migration. (#2942)
• Improved OIDC authentication assurance and evidence reporting. (#2942)

Existing installations are not automatically switched to passwordless authentication. Existing passkey and password behavior remains unchanged until administrators configure or apply the new policy options. Upgrading does not automatically delete password hashes, invalidate password reset material, remove credentials, or apply a recommendation. (#2942)

ACTION REQUIRED

Before enabling password removal or strict passwordless policies: (#2942)

1. Review the recommendations and preview their configuration impact.
2. Confirm required recovery routes and notification delivery are operational.
3. Ensure users have the required number and diversity of passkeys and verified security contacts.
4. Configure FIDO Metadata Service and risk-provider integration where required.
5. Complete any legacy credential backfill and review unknown legacy attestation evidence.
6. Test recovery, compromise response, temporary access passes, and administrative approval procedures.
7. Complete the rolling upgrade before activating destructive password-lifecycle policies.

BREAKING CHANGE

Committed password-hash removal is irreversible for the affected user. Reverting the application version does not restore the password. The user must continue with passkeys or complete an authorized password-recreation process if the configured policy permits it. (#2942)

Configuration and rollout guidance: UserStore passkeys, passkey policy reference, passkey security operations, and Account Management and account security. (#2942)

OpenID Connect interoperability and explicit claim disclosure

Standards compatibility is improved across authentication, token processing, and logout. Expanded automated conformance validation provides more consistent verification of supported OpenID Connect and FAPI capabilities during development and release testing. This supports certification preparation but does not itself establish OpenID certification. (#2944)

ProAuth now separates trusted authentication context from claims disclosed to applications. Claim rules control optional issuer identifiers, profile claims, and federation data without allowing removed claims to be restored afterward. The v2 APIs and editor support explicit claim input sources, UserInfo destinations, and disclosure either always or when requested. Existing v1 updates preserve configuration that v1 cannot represent. (#2944)

BREAKING CHANGE

Review edition-specific claim disclosure and application dependencies before upgrading: (#2944)

• Existing Enterprise configurations: Customer-authored rules are preserved and are not automatically supplemented. Applications requiring optional pa_iss_* identifiers need explicit issuer-context permission. UserInfo requires an explicit destination; Both continues to mean access token plus ID token. Review broad federation rules for unnecessary disclosure. Profile claims removed by filtering are no longer restored afterward.
• Starter/Business and newly generated defaults: Defaults disclose requested standard profile claims and explicitly enabled ProAuth capabilities. Exact pa_iss_* and available fed_* names can be requested through the claims parameter for ID tokens and UserInfo without adding rules in Starter/Business. Standard scopes and wildcard requests do not opt into these claim families. Starter/Business defaults are immutable; existing Enterprise rules remain unchanged.
• API access tokens: Immutable defaults do not disclose optional issuer or federation claims in access tokens. Requesting these claims for ID tokens or UserInfo does not restore them in API access tokens. Review dependent API authorization policies and establish a supported migration before upgrading. Enterprise configurations can explicitly permit required access-token claims. Optional issuer-identifier getters can return null.
• Authentication assurance: Claim rules cannot manufacture acr through constants or federation-claim renaming. This release's built-in authentication flows do not produce verified ACR values; constrained essential ACR requests fail rather than assert unverified assurance. Existing MFA remains available. Integrations relying on transformed acr require a supported assurance implementation before upgrading.

See Upgrade: trusted context and claim disclosure for configuration, application changes, reauthentication, and deployment ordering.

Security

Security

System-provided passkey cryptography

Passkeys now use cryptography provided through .NET and the operating system. The third-party NSec.Cryptography dependency has been removed to support customers with cryptography and export-control requirements, particularly deployments distributed to China. The EdDSA/Ed25519 compatibility change is detailed above. (#2941)

Enterprise UserStore security and lifecycle controls

UserStore authentication results now reach the central OIDC flow through purpose-bound, expiring, single-use authentication ceremonies. ProAuth centrally validates the tenant, client, authorization request, identity provider, user, browser context, and authentication evidence before deriving the subject, authentication methods, assurance, and authentication time. (#2943)

Additional controls strengthen account security and lifecycle management: (#2943)

• Understandable typed password policies and versioned recommendations. (#2943)
• Hardened password reset with hashed, expiring, single-use artifacts and durable delivery. (#2943)
• Unified invitations for UserStore and federated identity providers, including expiry, reminders, cancellation, supersession, approvals, application assignments, and group assignments. (#2943)
• Secure email and login-name changes during UserStore invitation redemption. (#2943)
• Purpose-bound verified security contacts and dual-verification contact replacement. (#2943)
• Distributed abuse controls for password login, passkey login, and password-recovery requests. (#2943)
• Governed provider-identity replacement that preserves the user's stable OIDC subject. (#2943)
• UserStore-user, tenant, and client-scoped session and renewable-grant revocation. (#2943)
• New Account Management journeys for security contacts, identity proof, and application sessions. (#2943)

Existing UserStore IDP instances are not automatically switched to hardened behavior. New password policy is activated separately from general UserStore hardening: existing instances retain their legacy password regex until an administrator previews and applies a typed recommendation or explicitly configures typed policy. (#2943)

ACTION REQUIRED

Before activating UserStore hardening: (#2943)

1. Apply the supplied ProAuth and UserStore database migrations.
2. Deploy the coordinated release to every ProAuth, AdminApp, worker, and supporting node.
3. Confirm that no older node or rollback ReplicaSet can receive traffic.
4. Preview the password-policy and UserStore hardening inventories.
5. Run the idempotent hardening backfill batches.
6. Resolve every quarantined canonical login-name conflict.
7. Inventory and reissue legacy invitations.
8. Review layered abuse-control capacities and CAPTCHA configuration.
9. Run the supplied Docker-backed certification gate for the production database and state-store topology.
10. Record the all-serving-nodes attestation and change acknowledgement before activating hardened semantics.

BREAKING CHANGE

After hardening activation, rollback to a pre-hardening ProAuth binary is unsupported. Authentication epochs and revocation cutoffs only advance, upgraded password hashes do not downgrade, cancelled legacy invitations are not restored, and completed identity replacements are not reversed automatically. (#2943)

Detailed guidance: UserStore enterprise hardening, password policy and recovery security, unified invitations, verified security contacts, layered abuse protection, identity and session security, migration, activation, and certification, and Account Management. (#2943)

Stronger client authentication and grant protection

Public clients retain supported PKCE and device flows with authentication method none. Confidential clients must authenticate using their registered token-endpoint method; neither PKCE nor DPoP replaces that authentication. Public authorization-code flows require S256 PKCE, and any issued PKCE challenge requires the matching verifier at redemption, including for confidential clients. (#2944)

DPoP requirements apply across supported token grants, and existing refresh-token key bindings remain effective. Authorization-code consumption and refresh rotation use shared-storage concurrency protection. Signed authorization parameters remain protected across login and consent, and revocation remains effective when an originating identity provider is temporarily disabled and later re-enabled. (#2944)

ACTION REQUIRED

Update the ProAuth.Bff client package with this server release. Auto with a configured client secret selects ClientSecretBasic; code redemption now sends HTTP Basic authentication to the discovered token endpoint, including with DPoP. Configure the same authentication method on the client registration. See BFF client authentication. (#2944)

BREAKING CHANGE

Client authentication migrations assign missing authentication metadata to none for public clients and client_secret_basic for confidential clients. Register POST authentication explicitly when used, including for PAR. Contradictory client registrations are disabled. Response types default to code, native loopback redirect exceptions require explicit native registration, and public/confidential type changes require a new client identity. (#2944)

The migrations revoke existing authorization codes and refresh tokens, and the state-store namespace transition invalidates previous stored tokens. Coordinate the rollout across all instances and reauthorize affected applications. See Client authentication and grant security migration. (#2944)

Infrastructure

Infrastructure

Compact, resilient FIDO metadata caching

FIDO metadata caching now omits embedded authenticator artwork and compresses the protected trust snapshot, reducing state-store traffic while preserving trust information and existing credential evidence fingerprints. The current catalog fits within the default Dapr message limit. Existing uncompressed snapshots remain readable and are replaced on the next successful refresh or signed import. Refresh failures, including snapshot size-limit failures, retain an installed last-known-good snapshot. (#2941)

ACTION REQUIRED

Upgrade all ProAuth nodes sharing the state store together: older binaries cannot read the compact snapshot. Preserve the shared Data Protection keys, and retain any previously increased Dapr/client limits until the old snapshot has been replaced and the compact snapshot successfully reloaded. (#2941)

Coordinated deployment and state-store requirements

Multi-instance UserStore installations must use a distributed state store with the required compare-and-swap (CAS) and time-to-live (TTL) semantics. The in-memory state store is supported only for single-instance deployments. (#2943)

For the OIDC and client security changes, apply the incremental SQL Server or PostgreSQL migrations before upgrading application instances coherently. Preserve shared data-protection keys and historical verification keys for the supported session-retention period, then verify affected client applications. Mixed runtime versions do not provide consistent claim-disclosure behavior. Legacy authorization codes and refresh tokens without protected disclosure state require a new login; existing sessions may also require reauthentication. In-flight signed-request continuations created before the upgrade must be restarted. (#2944)

AdminApp

AdminApp

Governed UserStore administration

New AdminApp workflows guide administrators through UserStore migration, activation, legacy invitation reissue, approvals, and identity replacement. These workflows support the coordinated hardening rollout and ongoing account lifecycle governance. (#2943)

Platform Stability

More dependable logout and account access

Logout handling improves correlation with current and retained recent sessions, including pairwise subjects and encrypted ID-token hints, while preserving confirmation and registered-redirect validation. Recent-session retention defaults to 24 hours. Account Management sign-in now correctly uses the ID token returned by the authorization-code token exchange, restoring access to account and passkey pages after login. (#2944)

Resilient trust metadata and token lifecycle

FIDO metadata refresh failures preserve an installed last-known-good trust snapshot. Shared-storage concurrency protection strengthens authorization-code consumption and refresh rotation, while revocation remains effective across temporary identity provider disablement and re-enablement. (#2941) (#2944)