ProAuth Release Notes

Appearance

Version3.3.0
Released
Compared To3.2.4

ProAuth 3.3.0 ​

ProAuth 3.3.0 lets protected APIs request stronger authentication and exchange a user's access token for a token restricted to a downstream API. This release also improves repeatability for YAML imports, deploys signed container images by digest, and preserves role assignments during upgrades from ProAuth 2.x.

ACTION REQUIRED

  • Before database migration, check for duplicate options with the SQL Server script or PostgreSQL script. Repair any records the script reports. The migration stops if duplicates remain and leaves the configuration available for repair. See Option import preflight and recovery. (#2965)
  • Before upgrading the .NET, native-client, or BFF packages, upgrade the server to a version that accepts dedicated routing parameters on authorization and token requests. For token exchange, deploy matching server, database migrations, AdminApp resources, and client packages. Use a CLI version that matches the backend for YAML provisioning. (#2903) (#2962) (#2963) (#2975)
  • Before enabling the federation claim allowlist, upgrade every instance serving requests so that all instances enforce the configured disclosure policy. (#2979)

Core ​

Core

Step-up authentication for protected APIs ​

Protected APIs can use verified authentication context to decide when an operation requires stronger authentication and request it through an RFC 9470 step-up challenge. Enable assurance policies through the API, YAML, or AdminApp for the integrations that need them. (#2903) (#2962)

The updated .NET, native-client, and BFF packages route requests with dedicated parameters by default and omit the legacy tenant token from acr_values. The server continues to accept legacy requests. During step-up, the BFF preserves the validated issuer through OIDC claim processing and requires a well-formed, absolute resource identifier. If step-up fails, the user keeps the existing BFF session and the operation is not automatically retried. (#2903) (#2962)

Policy-controlled token exchange ​

A receiving API can exchange an authorized user's access token for a downstream token with a limited scope, audience, and lifetime. Configure client-owned policies through Management API v2, the CLI, or AdminApp. Policies support exchange-specific binding requirements, scope and audience mappings, and lifetime limits. Administrators can also set tenant-wide requirements. (#2963)

Existing clients default to Legacy mode, which preserves supported bearer and federation flows, refresh behavior, and source-client allowlists. In Policy mode, the receiving API must validate the sender's proof on the original request. Exchanges support bearer, DPoP, and mTLS tokens with independent keys or certificates for each API. A sender-constrained input token must retain sender protection on exchange. (#2963)

For long-running delegated sessions, enable Allow refresh tokens on the matching policy and request offline_access. Policy refresh tokens are disabled by default. Each refresh retains the API binding and checks current authorization. Normal refresh lifetime, rotation, and session controls apply. (#2963)

BREAKING CHANGE

Review integrations that construct token-exchange requests or consume token responses and errors. (#2963)

  • Token requests and responses. Send one RFC 8693 identifier in requested_token_type. Legacy callers that need a separate refresh token should request offline_access with an access-token exchange. An explicit refresh-token exchange returns the refresh token in access_token, identifies it through issued_token_type, and sets token_type=N_A. (#2963)
  • Exchange targets. Each resource must be an absolute URI without a fragment. Move logical names to audience or register and send an absolute resource URI. Denied targets consistently return invalid_target. (#2963)
  • Subject and actor tokens. Handle invalid_request for invalid, expired, or revoked exchange subject tokens if your integration previously handled invalid_token. Legacy mode now rejects the previously ignored actor_token and actor_token_type parameters. Remove them from Legacy requests. These error changes apply to token exchange only. (#2963)
  • Introspection. Update consumers that expect access_token in the token_type field. Access-token introspection reports Bearer or DPoP, including in signed responses. Refresh-token introspection omits this optional field. (#2963)

Claim disclosure and OIDC claim requests ​

Administrators in all editions can set FederationClaimAllowlist on a client application to limit raw federation claims to exact claim names without writing custom rules. Clients without an allowlist continue to use existing defaults and Enterprise Always rules. New authorizations use the updated token-disclosure settings. Existing refresh grants retain their recorded token results, while UserInfo evaluates the current settings. (#2979)

OIDC claim constraints now match complete JSON values, including structured addresses. Send numeric and boolean constraints as JSON numbers and booleans. Empty values arrays are rejected. Claim templates support documented user, client, profile, metadata, and context fields. Update templates that relied on unrestricted entity navigation to use those fields. The release also updates discovery metadata, configuration guidance, and documentation navigation. (#2979)

YAML provisioning and view exports ​

  • Options. Repeated imports now check every result page, preserving option identities and undeclared credentials in large collections. The CLI reports ambiguous duplicates, and the database prevents new duplicates within the same owner. (#2965)
  • Role assignments. Reimporting an unchanged assignment preserves its ID and access. If its principal, role, or scope changes, the CLI stops and retains the original assignment. To replace it, provision the new assignment with a new stable ID, verify access, then explicitly revoke the old one. Account for the temporary overlap in permissions. (#2973)
  • Child ownership. The CLI checks that an existing child belongs to the parent declared in YAML before updating it. A foreign child ID or conflicting owner field stops that operation and leaves the child intact. Correct the manifest before retrying. Earlier successful operations remain applied, and valid updates retain their concurrency checks. (#2974)
  • Provisioning order. Imports now create client-scoped claim rules after their declared clients exist and apply token-exchange policies after client authentication settings and tenant relationships. Fresh deployments and repeat imports can use the same manifest. Inline claim-rule creation, relationship modes, and server validation remain supported. If a sequential import fails, correct the prerequisites and reimport the retained manifest. (#2975)
  • Redirect URIs. For an entry without an ID, the CLI searches all pages for an exact URI and redirect-type match within the client. It reuses a unique match, handles repeated entries in the manifest, and stops on ambiguous matches without deleting records. Concurrent imports with the updated CLI generate the same ID for an identical new redirect, so the database primary key protects against duplicates. This change requires no database migration. (#2977)
  • Stable child IDs. Child IDs remain optional, and the CLI warns when they are omitted. Retain stable IDs for updates. Changing an ID-less redirect URI adds another entry. Other child types with optional IDs keep their previous creation behavior, and older CLIs or other API callers can still create duplicates. Options and keyed metadata retain their own reconciliation rules. The guide and samples show how to retain existing IDs and resolve GUID templates once. (#2977)
  • View exports. Filter by an ordinary route or a plain GUID. The CLI escapes apostrophes, treats query-like text as literal input, and rejects invalid GUIDs or blank filters locally. Existing outer-quoted routes still work. For backslash sequences the query API cannot represent, export by ID. Unfiltered exports include all pages. Canonical React view definitions can be exported and reimported, and the YAML guide distinguishes them from legacy wrappers. (#2976)
  • Client key sets. Use proauthcli data import with a standalone ClientAppKeySet document containing the key-set ID and client application ID to add or update just that key set on an existing client. (#2991)

Infrastructure ​

Infrastructure

Signed images and hardened Helm defaults ​

The Core and AdminApp charts now deploy each release's signed application and Job images by digest. Existing repository and tag overrides, precreated Secrets, and customer-managed service accounts remain supported. Cluster operators choose whether to enforce signature verification. The guide includes configuration examples and instructions for copying signed images to a private registry. See Container and Kubernetes security. (#2980)

ACTION REQUIRED

Review these Helm settings where they apply to your deployment. (#2980)

  • Mount writable storage at any path where a custom extension writes files. (#2980)
  • Enable kubernetesApiAccess.application for applications that call the Kubernetes API. (#2980)
  • If migrations can exceed the new 30-minute Job deadline, increase deploymentJob.activeDeadlineSeconds or set it to 0 to omit the deadline. Completed migration Jobs are retained for deployments that wait for them. (#2980)

Internal Dapr discovery and callbacks ​

Core and AdminApp now return HTTP 404 for Dapr discovery on the public listener. Core also rejects public pub/sub callbacks. Authorized Dapr service invocation continues on the internal HTTP listener with the same authentication, tenant isolation, and role permissions as the public API. Standard Helm deployments can use their existing values. (#2981)

ACTION REQUIRED

For custom manifests or image-only upgrades, point each Core and AdminApp sidecar's dapr.io/app-port or --app-port at the internal HTTP port (default 8081). Keep public traffic on the external port (default 8080). If you previously set ports through Helm envvariables or a custom Dapr app-port annotation, configure distinct external and internal ports through deployment.containerPort and deployment.containerInternalPort. (#2981)

HTTPS from Ingress or Gateway to ProAuth ​

Core and AdminApp now support TLS between an Ingress or Gateway and the application containers. Enable it independently for public traffic and internal endpoints using a Kubernetes TLS Secret or a certificate issued and renewed by cert-manager. Configure the controller to trust the issuing CA and verify the backend hostname. Existing Helm deployments continue to use HTTP until TLS is enabled. See the Helm chart configuration guide. (#2982)

Observability ​

Observability

Database migration and resource deployment diagnostics ​

Schema deployment, module initialization, and root data initialization now use the configured logging exporters throughout the migration Job. With OTLP-only logging, all three phases appear under the Job's service name in the telemetry backend. Combined exporters also send these records to the Job console. If entity validation blocks initialization, the final Error-level message identifies the attempted action and the rules that rejected it. (#2984) (#2985)

The AdminApp resource Job now identifies which stage of view deployment failed, from sign-in and local file parsing to validation and apply. For backend rejections, it logs the HTTP status, available validation messages, and request or trace IDs to help diagnose invalid definitions, missing permissions, or stale revisions. (#2989)

Security ​

Security

Dependency security updates ​

Patch and minor updates to NuGet and npm packages, the .NET SDK, and runtime and base images incorporate upstream security fixes. The dependency updates require no separate customer action. (#2993)

AdminApp ​

AdminApp

Client claim rules, group membership, and key usages ​

Administrators can create rules for selected clients or narrow an existing tenant-level rule to specific clients. AdminApp saves the scope and client assignments together, checks for concurrent changes, and reports assignment-save failures. Saved assignments persist after reload. (#2972) (#2983)

The Member of Groups picker supports search and paging, and membership changes for locally managed ProAuth users persist after saving. Client key sets retain all selected usages, including keys used for both client assertion signing and request object signing. (#2983)

Application sign-out and SSO logout ​

Choose Sign out of Admin App to keep working in other applications or SSO logout to also end browser single sign-on. The confirmation page provides a Sign in button. Applications using the ProAuth BFF can offer both options. Existing BFF integrations default to SSO logout. (#2995)

Platform Stability ​

.NET client discovery, renewal, and revocation ​

  • Tenant-path discovery. The OIDC client preserves issuer paths when loading metadata and rejects issuer mismatches, redirects, and insecure endpoint URLs. Advertised HTTPS endpoints on other origins remain supported. Set Authority to the exact advertised issuer, including any trailing slash. For a tenant route that advertises a root issuer, configure the root issuer as the authority. (#2968)
  • FAPI token renewal. Clients using private_key_jwt now use the configured authorization-server issuer as the client assertion audience. This fixes invalid_client errors that could interrupt API access during automatic renewal while an application session was active. Existing security checks still apply. (#2960)
  • Token revocation. The OIDC client accepts successful RFC 7009 responses with empty or non-JSON bodies. It still reports HTTP and OAuth errors, transport failures, and cancellation. APIs that validate JWTs locally retain their existing revocation behavior. (#2969)
  • Consent forms. Selecting Accept submits approval and Deny submits rejection. Loading feedback appears on the selected button. Custom named submit buttons using the shared form script also retain their selected action. (#2961)
  • UserStore password login. The CAPTCHA appears as soon as the failure threshold is reached or abuse protection requires a challenge. Completing Turnstile clears the verification prompt. An incorrect password still shows its own error and the next attempt gets a fresh challenge. (#2992)
  • Account security pages. Passkey registration is easier to find, and Active Sessions gives application names and session details more room on desktop and mobile. Sign-in identity history is collapsed at the bottom of the profile and shows recognizable provider names when expanded. Account pages and passkey recovery use the selected language for actions and status messages and preserve custom label text. (#2994)

Upgrades from ProAuth 1.x and 2.x ​

  • Invitation Application. On installations originally created on v1, obsolete confidential-client settings could block root data initialization after a successful v2-to-v3 bridge. The initializer repairs the recognized built-in registration, expires its obsolete secret, and revokes its database-stored tokens while preserving users and client relationships. If the bridge already completed, rerun the complete initializer (multicommand all) during the documented maintenance window. This repair requires neither manual SQL nor a second bridge run. If v3 served traffic with the affected registration, follow the migration guidance for external state-store grants and independently validated JWTs before resuming traffic. (#2986)
  • Built-in AdminApp views. On installations upgraded from v1, the resource Job could import labels and then fail with HTTP 400 when deploying views. After upgrading Core, rerun the matching AdminApp resource Job. It removes recognized obsolete built-in views as it installs the current definitions, without manual database cleanup or a bridge rerun. (#2987)
  • Role assignments. The 2.x-to-3.x bridge now preserves user, group, and service-principal role assignments, including access inherited through nested groups. This fixes missing AdminApp navigation and lost API permissions after upgrade. If you already ran an earlier bridge, use proauthcli migrate recover-v2-role-assignments to preview missing assignments and select which to restore. Recovery recognizes assignments you already repaired and lets you keep intentional revocations. (#2988)

Helm validation with default Dapr components ​

The Core and AdminApp charts pass helm lint with default Dapr components enabled. Existing Helm values and Secret names, contents, and references continue to work. (#2990)