Originally published on PkLavc.
Confirmed facts
On 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.
Technical analysis
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.
Continue reading: Full technical article on PkLavc
Explore more technology articles: PkLavc Tech Blog
Top comments (0)