Client Authentication In ProAuth 3.2: Make The Registration Contract Explicit

On this page

A server application can send a valid PKCE verifier and a valid DPoP proof while still failing to authenticate as the registered client. Each proof answers a different question. Treating them as interchangeable leaves a gap in the integration contract.

ProAuth 3.2.0 strengthens that contract across client authentication, grant handling and redirect registration. It builds on the JWT and mTLS methods shipped in 3.0, with explicit rules for how an application presents its registered credentials.

Three proofs, three responsibilities

Protection	What it establishes	Integration responsibility
Client authentication	The identity of a confidential client	Use its registered Basic, POST, JWT or mTLS method
PKCE	Possession of the verifier associated with an authorization code	Preserve the verifier and redeem the code with it
DPoP	Possession of the key bound to a token or authorization code	Generate and validate the required request proof

In 3.2, confidential clients authenticate using their registered token-endpoint method even when they use PKCE or DPoP. Public authorization-code clients require S256 PKCE. When a code was issued with a PKCE challenge, its matching verifier is required at redemption, including for confidential clients.

sequenceDiagram
    participant Client
    participant ProAuth
    Client->>ProAuth: Token request with required proofs
    ProAuth->>ProAuth: Check registered client authentication
    ProAuth->>ProAuth: Check required verifier and possession proof
    ProAuth-->>Client: Tokens or protocol error

This is useful for platform teams standardizing integrations: the application owner can describe exactly which proof satisfies each requirement. The client-security migration guide documents the complete rules.

Defaults are recorded, rather than inferred by each caller

The migration assigns missing authentication metadata to none for public clients and client_secret_basic for confidential clients. Existing explicit registrations are preserved; contradictory client-type and authentication-method combinations are disabled for correction.

An application sending a secret in the POST body needs an explicit client_secret_post registration. Review both token redemption and PAR, rather than assuming that a successful call to one endpoint proves the complete flow.

Public applications remain public: supported PKCE and device flows use authentication method none, and secrets should not be distributed to them. Changing an existing client’s public/confidential classification requires a new client identity and retirement of the previous grants.

Redirect and response-type choices become explicit too

Allowed response types default to code. Other supported combinations need explicit registration. For native HTTP loopback redirects, the documented port exception requires explicit native-application registration; marking the client public alone does not enable it.

These settings give reviewers a smaller contract to inspect. Which response type can the application request? Which exact redirect is registered? Is the loopback exception deliberate? Use the v2 management surface to inspect the full configuration.

Include the BFF package in the deployment

ProAuth BFF applications need the updated package with this server release. With a configured secret, Auto selects ClientSecretBasic, and code redemption sends HTTP Basic authentication to the discovered token endpoint, including with DPoP. Register the same method on the ProAuth client. See BFF client authentication.

For an existing installation, inventory client registrations before deployment, apply the documented migrations and coordinate the runtime rollout. Existing codes and refresh tokens are revoked by the security transition, so include application reauthorization in the plan.

For a new evaluation, test a valid request and then omit each required proof separately. The useful evidence is that missing client authentication, a wrong verifier and a mismatched possession key each fail at their own boundary.