On this page
An identity server needs internal context to validate authentication. Applications do not necessarily need to receive all of that context. Treating those as the same dataset makes it difficult to limit disclosure without accidentally changing authentication behavior.
ProAuth 3.2.0 separates trusted authentication context from externally disclosed claims. Claim rules determine optional issuer identifiers, profile data and federation data, including their destinations. Removed claims are not silently appended again after filtering.
Decide permission and destination separately
A client requesting a claim does not grant itself permission to receive it. Disclosure rules and the product’s defaults establish what may be released. Requests then select claims within that permitted contract.
flowchart TD
Context[Trusted internal authentication context] --> Policy[Disclosure permissions and filtering]
Request[Client requests specific claims] --> Policy
Policy --> ID[ID token]
Policy --> AT[API access token]
Policy --> UI[UserInfo]Destinations are explicit. Both continues to mean access token plus ID token; it does not include UserInfo. If UserInfo should return a claim, its destination needs to say so. Use the v2 APIs and editor to inspect the complete configuration, because the legacy v1 representation cannot express every destination extension.
The claim-disclosure configuration guide provides examples. The upgrade guide explains compatibility and application changes.
Review the edition-specific contract
Existing Enterprise customer rules are preserved. The upgrade does not supplement them with new permissions. Applications requiring optional pa_iss_* identifiers need explicit issuer-context permission, and broad federation rules deserve review for unnecessary forwarding.
Starter and Business editions use immutable defaults. These disclose requested standard profile claims and explicitly enabled capabilities. Exact available pa_iss_* and fed_* names can be requested through the claims parameter for ID tokens or UserInfo. Ordinary scopes and wildcard requests do not opt into these claim families.
Those defaults do not disclose the optional issuer or federation claims in API access tokens. Requesting a claim for an ID token or UserInfo does not put it in the API token. An API depending on such a claim needs a supported migration; substituting an ID token for an access token is not that migration.
Do not manufacture authentication assurance
Profile transformation and authentication evidence have different responsibilities. The published 3.2.0 release notes state that claim rules cannot create acr through constants or renamed federation claims, and that the release’s built-in flows do not produce verified ACR values. Existing MFA remains available, but applications must not infer a verified assurance level from an arbitrary transformed claim.
The current documentation can evolve beyond a particular binary. For deployment, check the release contract for the exact version being installed before relying on additional assurance behavior described by newer documentation.
Test a new authorization and a refresh
Inventory claims used in client login, UserInfo calls and API authorization separately. Check whether each is required, which rule permits it and where it is disclosed. Include a request that deliberately omits optional issuer identifiers so missing-claim handling is tested.
After changing rules, start a new authorization and verify initial tokens, UserInfo and refreshed tokens. Existing authorizations retain their recorded token-disclosure results; a configuration edit does not rewrite their history.
The 3.2 deployment guidance requires coordinated instances and reauthentication or reauthorization for affected state. Schema compatibility alone does not make a mixed-version fleet apply consistent disclosure behavior. Make the claim inventory an application acceptance check before deploying the release.