On this page
A token endpoint can receive the same authorization code twice, or two refresh requests can arrive at different instances at nearly the same time. The security decision must remain consistent across the deployment.
ProAuth 3.2.0 strengthens authorization-code consumption and refresh rotation through shared-storage concurrency protection. It also applies registered DPoP requirements across supported token grants and preserves revocation when an originating identity provider is temporarily disabled and later re-enabled.
These changes extend the DPoP capability introduced in 3.0. They concern the state around issuance and reuse, as well as the token’s cryptographic proof.
Make grant consumption a shared decision
Authorization codes and rotating refresh tokens cannot depend on an instance-local decision about whether a grant was already used. Shared-storage protection serializes redemption so concurrent requests cannot independently accept the same consumable grant.
flowchart TD
A[Token request at instance A] --> Storage[Shared storage serializes grant consumption]
B[Concurrent request at instance B] --> Storage
Storage --> Valid[Validate current grant state]
Valid --> Consume[Perform permitted consumption and issuance]
Valid --> Reject[Reject an invalid or consumed grant]Concurrency protection is not a delivery guarantee. The client-security guide notes that a failed state-store issuance can consume the grant without producing a response. After the documented invalid_grant outcome, restart authorization. Applications should avoid concurrent token retries and test recovery from an uncertain result.
Carry the possession requirement through the grant lifecycle
In 3.2, registered DPoP requirements apply to authorization code, refresh, client credentials, device code and token exchange grants. Existing refresh-token key bindings remain effective after configuration changes. A client cannot redeem a bound refresh token with a replacement key simply because an option changed.
The receiving API still validates the DPoP proof independently, including method, URI, token hash and replay. Server-side grant protection does not replace resource-server validation. The DPoP configuration guide covers those proof checks.
FAPI refresh behavior remains a distinct contract. ProAuth’s FAPI clients use stable sender-constrained refresh tokens; they are not converted into rotating refresh tokens by this change. Verify the client’s effective profile before interpreting a successful refresh response. See the FAPI guide.
Keep a revocation decision effective
Temporarily disabling an identity provider must not make a revoked grant usable when that provider returns. ProAuth 3.2 preserves revocation across that disable/re-enable lifecycle.
Keep the scope of this control clear. A self-contained access token accepted by an external API can remain valid until expiry unless the resource server checks revocation. Revoking server-managed authentication state does not make every previously issued JWT disappear from every resource server.
For account security responses, document which sessions and renewable grants are invalidated and how each API enforces its remaining token lifetime. The identity and session guide describes scoped revocation.
Test the topology that will serve production traffic
Use the supported shared state-store configuration for a multi-instance deployment. Exercise concurrent redemption, interrupted refresh, a mismatched DPoP key and revocation followed by provider disablement and re-enablement.
Existing deployments need the coordinated migrations and runtime upgrade described in the 3.2 release notes. The token state-store namespace transition invalidates previous stored tokens, and the migrations revoke existing codes and refresh tokens. Plan application reauthorization and verify the resulting login journey before reopening traffic.