Remove the specific authorization at its issuing account, verify the scope of revocation, and handle app sessions and retained data separately.
To stop a connected app accessing an account, remove the specific connection in the account that granted it. Deleting the app from a phone, closing its tab or changing the account password may not revoke that authorization. Check whether the connection is used to sign in, read data, perform actions, or more than one of these.
Revocation, app-account deletion and deletion of previously copied data are different outcomes. Decide which you need before pressing a destructive control. This guide concerns an authorized owner retiring an integration, not removing another person’s account.
Find the account that issued permission
Open the identity or data provider through a known official route. Confirm the personal or organization account, tenant and environment. A connection named Calendar Helper in your personal profile may be unrelated to the company’s similarly named integration. Record the app identity, permissions, owner and expected tasks without copying tokens.
Review the connected-app or authorized-app listing. Compare the publisher, creation context and permissions with the app you intend to retire. For organization-managed accounts, an administrator policy or centrally installed application can require a different offboarding route.
Automation credentials are not always OAuth grants. For a WordPress application password, use the specific application-password revocation workflow. A browser login, an API key and an OAuth connection should not be treated as interchangeable merely because all allow some access.
Understand the links an app can have
| Connection | What removal can address | Review separately |
|---|---|---|
| Permission to access provider data | Future use of granted API access | Already-copied data and other credentials |
| Federated sign-in link | Use of that identity provider to enter the app | Alternative sign-in and existing sessions |
| The app’s own session | Current access within the app | Background authorization at the provider |
| Installed software | Local installation and some local state | Server permission and app-held records |
Google documents several linked-app categories, including Sign in with Google and access to account data. Its instructions distinguish stopping automatic sign-in from deleting app-held data. Those categories are a concrete example; another provider’s labels and revocation scope must be read on their own terms.
If federated sign-in is your only route into an app whose records you need, establish its supported alternative before removing the link. An email address on an app profile does not prove a local password exists. Do not create a second account and assume its records will merge automatically.
A fictional reporting integration being retired
Imagine a fictional publisher that authorized a reporting app to read a calendar. The app has a dashboard session and stores monthly summaries. The publisher wants future calendar access stopped while retaining summaries needed for internal reporting.
The publisher confirms the provider account, exports only permitted reports through supported controls and removes the calendar permission. Then the publisher signs out of the reporting app and checks its retention/deletion controls. Summaries do not disappear merely because the provider’s grant was removed.
Suppose the app also used the provider for sign-in. Before disconnection, the publisher reads whether alternative sign-in can be established and whether the app account must remain accessible for a deletion request. This changes the sequence, not the requirement to end unwanted data access. No real export or revocation is claimed here.
What token revocation means
RFC7009 defines OAuth token revocation. Related access tokens, refresh tokens and the underlying grant can be affected according to the authorization server’s policy, with practical propagation limitations. It does not say removing one app deletes every session or every copy of data.
An access token authorizes permitted resource requests. A refresh token can obtain further access tokens under the provider’s rules. Neither is your account password. Treat actual values as secrets and let supported settings or a maintained integration manage the revocation exchange.
Current OAuth security guidance calls for restricted token privileges and protection of refresh tokens. For an owner retiring an app, establish which authorization is ending and how the provider enforces the change. Avoid claiming immediate universal invalidation when the product documents narrower behavior.
Make a deliberate removal
- Identify the app, issuing account and permissions.
- Preserve permitted records and a supported sign-in route if the app account must remain accessible.
- Remove the intended data grant or sign-in connection through the provider’s control.
- Read the confirmation and record its scope and time without secret values.
- Review app-side sessions, scheduled tasks, installed components and retained data separately.
If compromise is suspected, prioritize containment over a leisurely export. Use the official incident route, remove affected access and review changes the app could make. Revocation does not undo earlier edits, sent messages or copied records. Correct those through the relevant system after establishing what occurred.
Verify future access rather than judging an old screen
Check the provider’s current listing and the app’s documented connection status. If an authorized maintainer can run a harmless controlled read using the retired integration, its refusal provides stronger evidence. Do not reconnect merely to see whether an old dashboard remains populated.
A cached report or open page could show retained data rather than fresh provider access. The private-page caching guide explains why visible content and current authorization differ. Ask the maintainer to distinguish a newly accepted request from a historical representation.
Review account recovery methods after a suspicious connection. The MFA and recovery guide addresses that independent boundary. Your next step is an inventory with one owner and retirement rule per app. Mark retained-data deletion and unverified propagation explicitly instead of reporting a broader result than the controls establish.
Watch for automatic reconnection during retirement
A scheduled job, browser extension or colleague can reauthorize an app after its connection is removed. Record which task owns the connection and disable the retired task through its supported configuration when appropriate. Otherwise a newly issued grant can look like failed revocation even though the original grant ended correctly.
For a shared organization integration, identify who is entitled to reconnect it and whether other users have separate grants. Removing your personal connection should not be reported as organization-wide retirement. Conversely, an organization-level removal can interrupt colleagues who depend on it and needs the authorized owner’s coordination.
Keep the final report specific: original grant removed, background task retired, app sessions reviewed, retained summaries preserved or deletion requested. If a deletion request is pending, say pending. A confirmation that future access stopped does not certify compliance with an app’s data-retention obligations.
Sources and verification
Editorial review 2026-10-17. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC7009: OAuth2 token revocationChecked Token revocation, cascading policy and propagation limitations.
Limits: Protocol mechanism, not a universal account-settings interface or deletion policy. - RFC9700: OAuth2 Security Best Current PracticeChecked Refresh-token protection and restricted token privileges.
Limits: Implementation guidance does not establish a particular provider revocation contract. - Google Account: Manage linked appsChecked Different link types and consequences of removing access.
Limits: Google-specific controls; previously copied app data needs separate treatment.