A Google OAuth access token lets an application act on behalf of a Google user, within the scopes that user approved. Depending on those scopes, the holder can read and send mail, open files in Drive, view calendars or reach other Google services that the user connected. The token is short-lived, but that does not make it safe: a leaked token is often pasted next to a longer-lived refresh token or the app’s client secret, and those keep the access alive. Remove the app’s access first, then check what it did.
Check your GitHub account for leaked secrets — free
- Provider
- Severity
- High
- Impact
- Source code and build access
- Checked live by LeakWatch
- Yes
- Revoke at
What a Google OAuth Token looks like
Google OAuth access tokens start with ya29., followed by letters, digits, hyphens or underscores. The length is not fixed, and Google has changed it over time:
ya29.…XXXX Google OAuth access token (masked)
The prefix is specific to Google’s OAuth access tokens, so a match is rarely a false alarm. The token usually appears in an HTTP request header, a JSON response or a configuration file, often beside a field called access_token. Refresh tokens are different. They do not start with ya29., last much longer and are the more dangerous find, because they can produce new access tokens for months. If you see a refresh token or a client secret in the same file, handle it as part of the same incident.
How Google OAuth Tokens get leaked
- Debug output. A script that prints its HTTP responses or its token store, then gets committed or pasted into an issue.
- Command output saved to files. A token printed by a command-line tool and redirected into a file in the project folder.
- Browser and mobile code. A client-side app that holds the token in plain storage where anyone who downloads it can read it.
- Configuration files. A tool’s token cache copied into a repository for a teammate, or left in a folder that was published.
- CI logs. A pipeline step that echoes an authorization header while calling a Google API.
What to do in the first hour
- Remove the app’s access. In your Google Account, open the page that lists third-party access, find the app that holds the token, and remove it. This invalidates the app’s refresh tokens, so it cannot mint new access tokens. An access token already issued keeps working until it expires, which usually takes about an hour.
- Rotate the client secret of the OAuth client in the Google Cloud console, if the leaked file held it. Then update the application with the new secret.
- Check the token’s scopes and expiry. LeakWatch and other tools can ask Google what a token is allowed to do and when it expires. If the scopes include mail, Drive or calendar access, treat the leak as a data exposure.
- Review recent activity in the services the scopes cover. For Gmail and Drive, look for messages sent, files shared or downloaded, and new filters or forwarding rules you did not create.
- Check the Google Account for new sign-ins, recovery details you did not set, and connected apps you do not recognize. Turn on two-step verification if it is not already active.
- Look for other credentials in the same file, especially refresh tokens, service account keys and API keys. See I accidentally pushed an API key to GitHub.
- Clean the repository and check the history for the token. Old commits keep the value, so removing access is the real fix. For a wider search, see deep-scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at Google
Access granted to third-party apps is listed on the third-party access page of your Google Account. Open it, choose the app that matches the leaked token, and remove its access. If the app belongs to a Google Workspace organization, an administrator may need to remove the grant from the admin console instead. Removing access ends the app’s ability to refresh its token. It does not change the access token itself, which expires on its own, so do not wait for the token to be refused before acting. The labels on Google’s pages change over time, so follow the wording on screen.
How LeakWatch detects it
The rule is called “Google OAuth Token”. It looks for the literal prefix ya29. followed by one or more letters, digits, hyphens or underscores. There is no minimum or maximum length, because the length is not fixed, and no nearby word is needed. The prefix is specific enough to be reported on its own. The severity is high, with the impact class for identity and code access. This type is checked live: LeakWatch can check whether a detected token is still active with a read-only request that asks Google what the token allows and when it expires. It does not read your mail, files or calendar.
LeakWatch can check whether a detected key is still active with a read-only request to Google. It never reads your data or spends your credits.
FAQ
The token expires in an hour. Do I still need to act?
Yes. The access token may already be expired when you find it, but the same file often holds something that lasts longer, such as a refresh token or a client secret. Those keep working until they are removed. Act on the whole file, not only the access token.
Will removing the app's access break my application?
Yes, the app will need the user to sign in again. Plan that for your own users. The short interruption is the cost of making sure the old refresh token stops working.
Is a Workspace account treated differently?
Yes. Google Workspace administrators can set policies on third-party apps and can remove grants for the whole organization. If the token belonged to a Workspace user, check the admin console as well as the personal account page.