Bypassing Google OAuth Consent with Leaked First-Party Client Secrets

TLDR: This research reveals how attackers can impersonate Google’s own first-party applications by using hardcoded OAuth client IDs and secrets found in public source code. By leveraging these legitimate credentials, an attacker can bypass the standard OAuth consent flow and gain unauthorized access to sensitive user data like Google Drive files. Security researchers and bug bounty hunters should prioritize searching for these leaked secrets in public repositories to identify potential account takeover vectors.

OAuth is the backbone of modern web authentication, but it relies on a fundamental assumption: the client application is who it says it is. When you see that familiar Google consent screen asking for permission to access your Drive or Gmail, you trust that the application requesting those scopes is legitimate. This research from Black Hat 2023 shatters that trust by demonstrating that Google’s own first-party applications—the ones you implicitly trust—often have their client IDs and secrets hardcoded into their source code.

The Mechanics of First-Party Impersonation

The vulnerability stems from the way developers handle OAuth credentials in client-side applications. Whether it is a desktop tool, a CLI utility, or a mobile app, these applications need a way to identify themselves to the authorization server. Developers frequently embed these identifiers directly into the binary or the source code. If that code ends up in a public repository, those credentials are effectively burned.

An attacker can take these leaked credentials and use them to initiate an OAuth flow. Because the client ID belongs to a "trusted" Google application, the authorization server treats the request as legitimate. In the proof-of-concept shown, the researcher demonstrated that by using a leaked client secret, they could bypass the standard verification process that usually blocks unverified third-party apps. The authorization server sees a request coming from a known, trusted entity and proceeds to grant the requested scopes without the usual friction.

Technical Breakdown of the OAuth Flow

In a standard OAuth 2.0 flow, the client application sends the user to the authorization server with a set of parameters, including the client_id and the requested scope. The server validates these parameters against the registered redirect URIs. The core issue here is that the authorization server cannot distinguish between the legitimate application and an attacker using the same client_id and client_secret.

Consider the following request structure:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/1BT...
client_id=32555940559.apps.googleusercontent.com
client_secret=ZmssLNjy2998hD4Ctg2ejr2
redirect_uri=urn:ietf:wg:oauth:2.0:oob
grant_type=authorization_code

When an attacker provides these valid credentials, the server issues an access token. The user is never prompted to verify the application because the server believes the request is coming from the trusted first-party tool. This effectively turns the trust model on its head. Instead of the user granting permission to an app, the app uses its "trusted" status to bypass the user's gatekeeping.

Real-World Impact for Pentesters

For those of us performing penetration tests or hunting for bugs, this is a goldmine. You are no longer looking for complex logic flaws in the OAuth implementation itself; you are looking for poor credential management. During an engagement, your first step should be to audit the client-side code of any application that interacts with Google APIs.

Search for client_id and client_secret strings in public GitHub repositories or within the decompiled assets of mobile applications. If you find a match, you have a potential path to impersonation. The impact is significant: an attacker can gain access to private user data, perform actions on behalf of the user, or even use the application as a staging ground for further attacks. This falls squarely under OWASP A07:2021 – Identification and Authentication Failures, where the failure to protect authentication credentials leads to complete account compromise.

Defensive Strategies

Defending against this is notoriously difficult because the vulnerability is baked into the application's design. For developers, the solution is to stop treating client secrets as static, hardcoded values. Use OAuth 2.0 for Native Apps best practices, which emphasize that native apps should be treated as public clients. Public clients do not use a client secret because they cannot keep it secret.

For enterprise administrators, the best defense is to restrict which applications can access your organization's data. Use the Google Workspace admin console to audit and block unauthorized applications. While Google has improved its detection of these first-party secrets, the cat-and-mouse game continues. If you are an admin, regularly review the list of authorized applications and revoke access for anything that looks suspicious or is no longer in use.

Security is not a static state; it is a constant process of verifying assumptions. This research serves as a stark reminder that even the most trusted entities can have significant blind spots in their authentication architecture. Keep digging into the source code, keep questioning the trust boundaries, and never assume that a "trusted" application is actually secure.