Google OAuth DPoP is not a WordPress setting you can switch on globally. It is a change to an integration's token exchange and refresh implementation. Before enabling it, identify the component that owns the Google connection and prove that its signing key survives the same deployment and recovery events as its refresh token.
What Google announced, and what it does not protect
Google's October 15 announcement describes DPoP binding for refresh tokens. Its short-lived access tokens remain bearer tokens. A stolen refresh token alone becomes less useful without its associated private key, but a compromise that exposes both is a different situation. DPoP also does not secure WordPress login cookies. See Google's announcement.
For a site owner, the immediate task is to ask the connector vendor about support, not paste cryptographic code into functions.php. This guide is an operational readiness review, not a drop-in OAuth implementation or a claim that a particular plugin supports DPoP today.
Map the connection before changing it
Draw the actual path for one connection: WordPress task, plugin or remote service, token endpoint, then Google API. A plugin can use a vendor-hosted connection service, so the refresh token may not live in your WordPress database at all.
Record these fields without collecting the secrets themselves:
| Field |
Useful answer |
| Connection owner |
Local plugin or named vendor service |
| Refresh location |
Web request, scheduled worker or remote job |
| Credential reference |
Internal record identifier, not token contents |
| Key location |
Protected signing service or secured key store |
| Recovery owner |
Person responsible for reconnecting affected accounts |
| Deployment boundary |
Single host, multiple workers or serverless instances |
The critical question is whether every legitimate refresh worker can use the correct key without distributing it unnecessarily. A token copied into a restored database will not establish that relationship by itself.
Restart: Same credential can use its key. Challenge: Fresh nonce and fresh proof. Recovery: Restore the connection deliberately. Revocation: Stop retries and reconnect. Proposed verification, not a customer test result.
Test deployment failures on an isolated connection
Use a dedicated test Google account with the smallest scopes needed. Do not clone a production token into staging to save a login step. The following are proposed acceptance tests, not results from a customer deployment.
- Connect once through the vendor-supported flow. Confirm that the integration completes a real, low-impact API request.
- Let the connector perform a normal token refresh. Record a redacted success event and the credential record identifier.
- Restart the worker or deploy a new application version. Repeat the refresh. A key generated only in process memory is a warning sign if the connection must outlive that process.
- Exercise the documented backup and recovery procedure in an isolated environment. Check whether the restored credential can still use its intended key. Do not silently replace the key and assume the existing binding changes with it.
- Test two workers attempting refresh near the same time. Ask the implementer to verify nonce handling and retry coordination rather than treating intermittent failures as random network noise.
- Revoke the test connection. Confirm that the UI asks for reconnection and does not loop indefinitely or replay queued business actions.
Distinguish a nonce challenge from a broken account
Google's DPoP adoption guide specifies proof construction and nonce handling. A use_dpop_nonce response requires a fresh proof using the returned nonce. Reusing the same failed request unchanged is not a valid recovery strategy. Initial code exchange and later refresh have different proof requirements; use the current guide and a reviewed implementation.
In your monitoring, separate an expected challenge followed by success from exhausted retries, an inaccessible key, an invalid grant and a denied application API request. Count outcomes, not raw credential values. Never log refresh tokens, private keys or complete authorization headers to a public debug file.
Decide whether to adopt now
Proceed only when the connector documents support, recovery has an owner, and the isolated tests pass. If the vendor has not implemented DPoP, preserve a supported connection and track the vendor's release rather than adding an HTTP header around an incompatible token flow.
DPoP does not repair a mismatched callback URL. Use the staging and production OAuth redirect review for that failure. For a connection that breaks after deployment, HandL WP can trace the integration boundary using redacted errors and a version inventory, without asking you to publish credentials.
References reviewed October 18, 2026. Diagrams and test fixtures are explanatory, not customer results.