cybersecurityConfirmedGoogle has announced support for DPoP (Demonstrating Proof-of-Possession) in its OAuth platform, significantly enhancing the security of refresh tokens against malware and man-in-the-middle attacks for developers.
Image source: GoogleOn October 15, 2026, Google announced that its OAuth Platform now supports DPoP (Demonstrating Proof-of-Possession). This new capability is specifically designed to sender-constrain refresh tokens, a measure intended to neutralize threats from Infostealer malware and adversary-in-the-middle (AiTM) attacks.
The implementation of DPoP involves cryptographically binding long-lived refresh tokens. Crucially, access tokens will continue to operate as standard Bearer tokens. This strategic distinction aims to provide robust credential security without introducing high-QPS (queries per second) API performance overhead, as access tokens are typically used for frequent API calls.
Additionally, Google confirmed that developers integrating multi-agent or Model Context Protocol (MCP) workloads can leverage Google Cloud Secure Token Service (STS) to manage secure token delegation across agent chains, utilizing this enhanced security mechanism.
The integration of DPoP into Google OAuth represents a significant enhancement to the security posture of applications relying on Google's authentication services. To understand its impact, it's essential to first review the fundamental roles and inherent vulnerabilities of OAuth tokens.
OAuth is an authorization framework that allows applications to obtain limited access to user accounts on an HTTP service. It typically involves two primary types of tokens: access tokens and refresh tokens. Access tokens are short-lived credentials used to access protected resources on behalf of the user. They are usually presented as 'Bearer' tokens, meaning that anyone in possession of the token can use it. This design prioritizes efficiency for frequent API calls but inherently carries a risk: if a Bearer access token is stolen, it can be immediately used by an attacker until it expires.
Refresh tokens, in contrast, are long-lived credentials used to obtain new access tokens once the current one expires. Their longevity makes them a prime target for attackers. If a refresh token is compromised, an attacker can continuously mint new access tokens, maintaining persistent access to a user's resources without needing their password. This vulnerability is particularly exploited by threats such as Infostealer malware, which exfiltrates credentials from compromised client devices, and adversary-in-the-middle (AiTM) attacks, where attackers intercept and replay tokens.
DPoP (Demonstrating Proof-of-Possession), defined by IETF RFC 9449, directly addresses the 'Bearer' token vulnerability by introducing cryptographic binding. The core mechanism involves the client generating a private/public key pair. When a client requests a DPoP-bound refresh token, its public key (or a cryptographic reference to it) is associated with the issued refresh token. Subsequently, whenever the client uses this refresh token to request a new access token, it must cryptographically sign a DPoP proof (typically a JSON Web Token, JWT) using its private key. This proof is then included in a DPoP header in the request.
The server, upon receiving the request, verifies the signature in the DPoP header against the public key bound to the refresh token. This verification process confirms that the client making the request is indeed the legitimate holder of the private key associated with that specific refresh token. This makes the token 'sender-constrained' – only the entity possessing the corresponding private key can successfully use the refresh token. An inference from this mechanism is that a stolen DPoP-bound refresh token becomes effectively useless to an attacker, as they would lack the necessary private key to generate a valid DPoP proof.
This DPoP implementation significantly enhances security against the identified threats. For Infostealer malware, even if a refresh token is exfiltrated from a compromised device, it cannot be used by the attacker without the private key, which is typically stored securely on the client and never transmitted. Similarly, in AiTM attacks, an intercepted DPoP-bound refresh token cannot be replayed or used by the adversary because they cannot generate the required cryptographic proof of possession. This directly mitigates the risk of persistent unauthorized access.
For developers, integrating DPoP support for refresh tokens implies specific changes to client-side OAuth implementations. Clients will need to generate and securely manage a private key, which could involve using hardware security modules (HSMs), secure enclaves, or other protected storage mechanisms depending on the client environment. They must also implement the logic to create and sign DPoP proofs for refresh token requests, including the appropriate DPoP header. While this adds complexity to client development, the resulting security benefits are substantial, leading to a more robust and trustworthy application.
The decision to keep access tokens as standard Bearer tokens is a practical engineering choice. Access tokens are used for high-frequency API calls, and requiring a cryptographic proof of possession for every single API request would introduce significant performance overhead. By applying DPoP only to the less frequently used refresh tokens, Google balances enhanced security for long-lived credentials with maintaining the performance efficiency of short-lived access tokens. This allows applications to benefit from stronger security without incurring a noticeable performance penalty on their core API interactions.
Furthermore, the announcement highlights DPoP's utility in advanced scenarios, specifically for multi-agent or Model Context Protocol (MCP) workloads. These environments often involve complex chains of automated agents or services that need to securely delegate and manage access to resources. The confirmed integration with Google Cloud Secure Token Service (STS) suggests that DPoP will facilitate a more secure model for token delegation in these contexts. An inference is that STS, in conjunction with DPoP, can ensure that tokens passed between agents are sender-constrained, preventing unauthorized agents from misusing delegated credentials and enhancing the overall integrity of multi-agent workflows.
While the security benefits are clear, the announcement did not disclose specific API changes or detailed implementation guides beyond the conceptual framework of DPoP. Developers will need to consult forthcoming documentation for precise integration steps. The announcement also did not specify how existing non-DPoP refresh token flows will be handled or if DPoP will become a mandatory requirement for new applications or specific types of clients. These details are crucial for developers planning their migration or new implementations.