What Google's DPoP support means for your OAuth app

Google’s OAuth platform now supports Demonstrating Proof-of-Possession (DPoP), a mechanism that ties a token to a cryptographic key held by your app, according to InfoQ. The detail that matters most is the scope. Google applies DPoP only to refresh tokens. Access tokens stay ordinary bearer tokens. If your app keeps Google refresh tokens, a thief who copies one could no longer use it without your app’s private key.

The background you need

OAuth 2.0 is the protocol behind Sign in with Google and behind any app that calls Google APIs for a user. The user approves access once. Google then hands your app tokens, so the app never sees the user’s password.

Your app usually gets two kinds of token:

• An access token is short-lived. Your app attaches it to each API call, for example to read a calendar or list Drive files.
• A refresh token is long-lived. When the access token expires, your app trades the refresh token for a new one. The user does not have to log in again. Server apps often store refresh tokens in a database for weeks or months.

Both are normally bearer tokens. Bearer means whoever holds the token can use it. The server does not check who is presenting it. InfoQ describes this as a “finders-keepers” model. Think of a festival wristband. Anyone wearing it gets in, whether or not they bought it.

That makes stolen tokens valuable. InfoQ names two common ways they get stolen:

• Infostealer malware runs on a victim’s machine and copies saved credentials, cookies and tokens. InfoQ cites RedLine and NodeStealer as examples.
• Adversary-in-the-Middle (AiTM) attacks put the attacker between the user and the real service, usually through a convincing phishing proxy, and capture what passes through.

Once an attacker has a token, they can perform a replay attack: they send the same token from their own machine, and the server accepts it.

DPoP fixes this by making the token sender-constrained. Your app generates an asymmetric key pair: a private key it keeps secret and a public key it can share. The token is bound to that public key. On each use, your app also sends a short signed message, a DPoP proof. That proof is a JWT (JSON Web Token, a compact signed data format). It is signed with the private key and covers details of the request, such as a timestamp and a nonce (a one-time value that stops an old proof from being reused). Google checks that the signature matches the key the token is bound to.

In the festival analogy, the wristband now only works if you also sign your name at the gate and the signature matches the one on file. The analogy breaks in one important way. A signature on a form can be forged by eye. A private key cannot be guessed, but it can be copied if the machine holding it is compromised. DPoP moves the secret you must protect from the token to the key. It does not remove the need to protect something.

DPoP is a general OAuth 2.0 mechanism, not something Google invented. The news is that Google’s OAuth platform now supports it.

What actually changed

According to InfoQ, three things are new on Google’s side.

Refresh tokens can be DPoP-bound. This is the core change. A Google refresh token issued to a DPoP client cannot be replayed without that client’s private key.

Access tokens are not. InfoQ reports that Google keeps access tokens as standard Bearer tokens. Google’s stated reasoning, as InfoQ relays it, is that long-lived refresh tokens are “the primary vector for persistent online impersonation”. Checking a signature on every single API call would also add cryptographic verification overhead to each request. So a stolen access token still works, but only until it expires.

Google is explicit about where DPoP does not fit. InfoQ reports that Google calls DPoP not appropriate for multi-agent workflows. If one AI agent hands a task to a second agent, the second agent would need to sign requests with the first agent’s private key. Sharing that key breaks the whole model. Google instead recommends Google Cloud Secure Token Service (STS). The second agent exchanges the upstream token for a new short-lived token bound to its own key, so no key is ever shared.

What was already true: bearer tokens were always replayable, and OAuth flows already relied on keeping tokens secret. Browser session cookies are a separate problem, and DPoP does not touch them. For cookies, InfoQ reports that Google and the Web Incubator Community Group (WICG) are developing Device Bound Session Credentials (DBSC). DBSC binds browser session cookies to device hardware such as a TPM (a security chip built into many computers).

What it means for developers who run apps

The refresh-token-only scope tells you where the benefit lands.

If your backend stores Google refresh tokens for many users, that table is the asset an attacker wants. A leaked database backup or a compromised log file could give someone lasting access to every user’s account. With DPoP, those stolen tokens are useless unless the attacker also gets the private key. That is a meaningful reduction in what a single leak can do.

If your app only holds short-lived access tokens, DPoP on Google changes little for you. Those tokens stay bearer tokens.

The cost is client-side work. InfoQ lists the requirements: generating cryptographic keys, handling timestamps and nonces correctly, building the right HTTP headers, and producing DPoP proof JWTs. Clock drift, a mishandled nonce or a lost key can all break token refresh. Plan for that in testing and monitoring.

The key now becomes the thing to protect. InfoQ notes that DPoP security ultimately depends on the security of the client. It cites Dhruv Agnihotri, who argues that single-page apps running in a browser are not entirely protected against misuse of the key. IETF guidance for browser-based apps, InfoQ reports, recommends the Backend-for-Frontend (BFF) pattern. In BFF, a small server you control holds the tokens and keys, and the browser only talks to that server. Agnihotri also proposes a zero-persistence approach for cases where you have no server-side infrastructure.

What to watch next: whether your OAuth client library adds DPoP support for Google, how DBSC progresses for browser sessions, and whether Google extends binding to access tokens later.

What we don’t know yet

The InfoQ report leaves several practical questions open:

• Is it opt-in or required? The report says Google introduced support. It does not say whether DPoP will ever be mandatory for any client type.
• Which clients and grant types qualify? The report does not list supported app types, libraries or OAuth flows.
• What happens on key loss? It does not say how recovery works if your app loses the private key a refresh token is bound to. Presumably users would have to re-authorize, but the report does not confirm that.
• Timeline for DBSC. The report says DBSC is in development with WICG. It gives no date for when browsers or Google services will use it.
• Access tokens later? Google’s reasoning is about per-request overhead today. The report does not say whether that could change.