---
title: "Deleted the app and changed your password? Google tokens are still 'alive': how to actually cut off third-party services' access to your account"
description: "Deleting an app and changing your password do not revoke OAuth tokens stored on third-party services' servers. To actually close off access to Drive, Calendar, and contacts, you need to manually check the lists of authorized apps in the settings of Google, Apple, Microsoft, and Meta."
date: 2026-09-14T12:34:00.000Z
lang: en
url: https://xab.info/en/posts/google-tokens-app-deletion-password-change-access-en
tags: [google, oauth-tokens, data-privacy, account-security, password-change, authorized-apps]
publisher: "XAB.info"
---

# Deleted the app and changed your password? Google tokens are still 'alive': how to actually cut off third-party services' access to your account

![Google logo on the glass facade of an office building: access tokens and account security after a password change](https://xab.info/media/2026/09/14/google-tokens-udalenie-prilozheniya-smena-parolya-dostup/google-tokens-udalenie-prilozheniya-smena-parolya-dostup-1.webp)

## 🎯 Key Points

- OAuth tokens are stored on the developer's servers, not on the user's device, so deleting the app does not revoke access
- Background activity of an app resets the six-month token lifetime, making access indefinite
- Changing your password invalidates tokens only for services with access to Gmail, but not to Drive, Calendar, and contacts
- To fully revoke access, you must manually check the lists of authorized apps in the settings of Google, Apple, Microsoft, X, and Meta
- Data already transferred to the developers' servers is not deleted when a token is revoked — a separate request to the service's support is required

Many users are convinced that simply deleting an app from their smartphone and changing their password is enough to make a third-party service lose access to their Google data. However, as it turns out, this logic only works halfway. Upon the first sign-in via Google, a third-party service receives what is known as an OAuth token — a digital "copy of a pass" that is stored not on the user's device but on the developer's servers. That is exactly why deleting the program from a phone or tablet does not notify the external server that the partnership has ended: the token remains valid until it expires or until the user revokes it manually.

### The OAuth token mechanism: why "deletion" is not the same as "revocation"

When you first log in to a third-party app via the "Sign in with Google" button, the system issues the service a time-limited access token. The standard lifetime of such a token is six months. But here lies the main trap: if the app accesses your calendar, contacts, or Drive at least once a week — for example, for background synchronization — the token's expiration is reset to zero and counted anew. As a result, with regular background activity, access becomes effectively indefinite, even if you haven't opened the app in months.

### Changing your password and two-factor authentication: why standard measures are not enough

The widely known advice to "change your password and enable two-factor authentication" only works partially in this case. Updating your password invalidates tokens only for services that have access to your Gmail mailbox. Meanwhile, authorization on websites, as well as access to Google Drive, Calendar, and your contact list, remain fully active even after changing your main password. Two-factor authentication also does not protect against data leaks through already stolen or compromised tokens, because the token itself is considered a verified pass — the system does not request re-verification if the token is still valid.

### Contradictory data

Standard cybersecurity recommendations, promoted for years by both tech companies and regulators, come down to two steps: changing your password and enabling 2FA. These are the measures presented as a "sufficient" level of protection. However, according to the data presented in an RBC.ua publication, these measures are categorically insufficient for revoking access to files, the calendar, and contacts. On the one hand, Google does confirm that changing your password affects session tokens associated with email. On the other hand, the token "renewal" mechanism through background activity and the storage of keys on the developer's servers makes the standard "deleted and forgot" scenario ineffective. Thus, there is a significant gap between the accepted practice and the actual mechanics of OAuth authorization, which is not disclosed in Google's own interface when changing a password.

### What to do: a step-by-step check of authorized apps

To fully close off access, users need to manually check the lists of authorized applications. In the Google connected apps dashboard, you should review all three categories: "Sign in with Google," "Account access," and "Connected accounts." For the Apple ecosystem, the check is performed in the "Sign-In & Security" → "Sign in with Apple" section of your Apple account or in iPhone settings. Microsoft users should go to the privacy and app access tab in their account settings. Similar sections exist in the settings of X (Twitter) and Meta — in the blocks managing connected apps and websites. It is important to understand: removing a connection in these interfaces only stops automatic authorization and further data collection.

### What can no longer be returned: data on the developers' servers

It is critically important to bear in mind that revoking a token does not erase data that has already been transferred. All files, contacts, calendar events, or login history copied to a third-party service's servers before the access was revoked remain there. To delete them completely, you must contact the specific app's support team and submit a separate request to delete your personal data. Without this step, "cleaning" your Google account remains formal: your digital footprint continues to be stored in other people's databases, even if access to the account is no longer granted.

## 🔍 Fact-Check Verification

- [Your password won't save you: why third-party services have been seeing your Google Drive for years](https://www.rbc.ua/ukr/news/parol-vryatue-chomu-storonni-servisi-rokami-1789389049.html) - Источник подтверждает ключевые тезисы: хранение токенов на серверах разработчика, недостаточность смены пароля и 2FA, необходимость ручной проверки авторизованных приложений. Конкретный срок в шесть месяцев и механизм сброса при фоновой активности изложены в рамках общей логики OAuth 2.0, но не подкреплены прямой ссылкой на документацию Google в тексте источника.

## ❓ FAQ

### Q: Why does deleting an app from my phone not revoke its access to my Google account?
**A:** Because the OAuth token issued at the first authorization is stored on the developer's servers, not on your device. Deleting the app from your phone does not send a revocation signal to the server, and the token remains valid until it expires or until it is manually revoked in Google's settings.

### Q: If I change my password, will everything be safe?
**A:** No. Changing your password invalidates tokens only for services that have access to your Gmail mailbox. Access to Google Drive, Calendar, and contacts is preserved. To fully revoke access, you need to manually remove the app from the list of authorized apps in Google's settings.

### Q: Does two-factor authentication protect against leaks through stolen tokens?
**A:** No. A token itself is a verified pass. If an attacker obtains a valid token, two-factor authentication does not trigger, because the system does not request re-verification for already authorized access.

### Q: Where can I check which apps have access to my Google account?
**A:** In the Google connected apps dashboard, you need to check three categories: "Sign in with Google," "Account access," and "Connected accounts." Similar sections are available in the settings of Apple, Microsoft, X, and Meta.

### Q: If I remove the connection to an app, will my data be erased from its servers?
**A:** No. Revoking a token only stops further automatic authorization and data collection. Data already transferred to the developer's servers remains there. To delete it, you must contact the specific service's support with a request to delete your personal data.