OAuth2 Token Compromise in Google Chrome

Uncovering how stored OAuth2 tokens could bypass MFA and grant access to core Google services.

Overview

When organisations adopt third-party identity providers such as Google, they often assume the authentication flow is secure by default. However, as this research engagement demonstrated, authentication boundaries can be fragile — especially when browsers cache powerful credentials in unexpected ways.

Cyber Defence investigators identified that Google Chrome stored OAuth2 refresh tokens in plaintext. Combined with Chrome’s auto-login workflow and the Google MergeSession mechanism, this refresh token allowed full access to critical Google services, including Gmail, even where multi-factor authentication (MFA) was enabled. :contentReference[oaicite:1]{index=1}

Context

What we set out to investigate

OAuth2 workflow analysis

We examined how Chrome requested, cached, and refreshed OAuth2 tokens during synchronisation and auto-login.

Security expectations

Users often believe Chrome’s stored credentials only permit harmless sync operations like bookmarks or tabs — an assumption we set out to test. :contentReference[oaicite:2]{index=2}

Threat landscape

Compromise of email accounts remains one of the most damaging footholds for attackers, enabling password resets, impersonation, and downstream account takeovers.

Discovery: Chrome’s powerful refresh token

During assessment, Cyber Defence observed that Chrome could log a user into Google services automatically if Chrome had ever been linked to a Google account for sync purposes. No reauthentication was required.

This behaviour implied that Chrome stored a powerful credential locally — far more powerful than a simple sync token.

Through intercepting browser traffic, we confirmed this intuition: Chrome was storing a full OAuth2 refresh token with broad access rights. :contentReference[oaicite:3]{index=3}

This token could be exchanged directly for new access tokens by calling:

POST /o/oauth2/token

Method

How we exploited the token

1. Obtained refresh token

Chrome stored the OAuth2 refresh token in plaintext in the user’s profile preferences file under <code>oauth2LoginRefreshToken</code>. :contentReference[oaicite:4]{index=4}

2. Exchanged refresh token

We exchanged it for a temporary access token using the hardcoded client_id and client_secret embedded in Chrome.

3. Obtained UberAuth token

We requested an ‘uberauth’ token via: <code>GET /OAuthLogin?issueuberauth=1</code>, leveraging the access token for authorisation.

4. Used MergeSession

We crafted a MergeSession URL to sign into powerful Google services, including Gmail:<br><code>https://accounts.google.com/MergeSession?...&continue=https://mail.google.com/</code> :contentReference[oaicite:5]{index=5}

Bypassing MFA

Even when the Google account was protected by multi-factor authentication, the refresh-token workflow bypassed MFA entirely. The OAuth2 token sat below the MFA layer and allowed Chrome to authenticate the user without additional validation.

This made the refresh token effectively as powerful as an Application-Specific Password (ASP) — and in some ways more powerful, because it interacted seamlessly with the modern OAuth stack.

In short: possession of the refresh token meant possession of the Google account.

Impact

Security implications

Complete Gmail access

Email compromise enables password resets, impersonation attacks, financial fraud, and data exfiltration.

Cross-service compromise

Many Google properties accepted the MergeSession flow, granting broad ecosystem access. :contentReference[oaicite:6]{index=6}

Token theft = account takeover

Any attacker with local access, malware capability, or a Chrome profile copy could silently hijack the account.

MFA erosion

Although 2-Step Verification blocked ASP attacks, the refresh-token route bypassed MFA controls entirely.

Recommendations

Cyber Defence issued the following remediation guidance:

• enforce encrypted credential storage and OS credential vault usage

• monitor for MergeSession requests and anomalous OAuth token exchanges

• restrict or disable Chrome account sync on sensitive systems

• implement device-based access policies to reduce token portability

• review OAuth2 scopes used by enterprise applications

• educate users about risks of browser auto-login features

Outcome

Results

Vendor engagement

Findings were escalated appropriately to Google’s security teams for review and mitigation.

Awareness raised

Organisations learned how browser token storage can undermine MFA protections.

Improved policy controls

Clients hardened Chrome usage policies on administrative, finance, and engineering systems.

Need to test your identity & authentication flows?

Cyber Defence specialises in uncovering weaknesses in OAuth, OIDC, SAML, and federation workflows — often where organisations least expect them.

Make sure trust boundaries are validated, not assumed.