How to Review Connected Apps and Remove Unneeded Permissions
Find apps linked to your accounts, check what they can access and disconnect them without deleting useful data or losing your login.
That tool you tried once may still have access to your calendar, files or profile. Deleting its browser tab does not remove the permission. Even uninstalling an app is not a reliable substitute for checking the account connection you approved during setup.
A connected-app review is a way to reduce those leftover relationships. The aim is not to disconnect every useful integration. It is to understand what each one does, keep the permissions you still need and remove the rest without breaking your own access.
Separate sign-in from data access
“Continue with Google” can be a way to identify you to another service. A separate permission screen might also allow that service to read or change particular account data. The two arrangements are related but not identical.
Google's linked-app guide separates sign-in, linked accounts and access to Google Account data. This matters when the same app appears under more than one connection type. Removing the sign-in relationship is not the same decision as removing permission to read a calendar.
Look at the actual permission description, not just the app name. “Read your profile” has different consequences from “read and change files.” Broad language deserves a closer look, even when the tool itself is familiar.
Use a small review note with four columns: app, purpose, permissions and decision. Do not copy confidential account identifiers or access tokens into the note.
Start with the accounts that hold the most data
Review the main email and cloud account first, then any account used for code, publishing or business administration. Follow the provider's own security settings to reach authorized apps or integrations.
For GitHub, the authorized-integrations documentation explains where to review permissions for GitHub Apps. For Apple accounts, Sign in with Apple management covers a different relationship. These examples are not interchangeable menus; use the guide for the account in front of you.
Check which identity you are signed into before changing anything. A personal account and a work account may both be connected to the same service. Record enough context to avoid disconnecting the wrong one.
If your employer manages the account, do not revoke an organization integration simply because you do not recognize its name. Ask the administrator what it supports.
Compare the permission with the job
A calendar scheduling tool may need access to availability. A photo importer may need selected images. A text-formatting utility requesting broad mailbox access needs a more convincing explanation.
Ask what the tool should be able to do today, not what you vaguely remember wanting during the trial. Read its current permission screen and help page. Where the provider offers narrower scopes, selected folders or read-only access, see whether those are enough.
Consider the difference between reading information and taking actions. A connected service that can send messages, edit documents or publish posts introduces consequences beyond data exposure. The stronger the permission, the more important it is to know who operates the service and how to revoke it.
Our Productivity directory can help with discovery, but a directory listing is not approval to connect a whole inbox. The same careful review applies to ordinary productivity tools and services using automated assistants.
Prepare an alternative login before disconnecting
Open the third-party service in a separate tab. Check whether it has an account password, another supported sign-in method or a documented process for changing identity providers. Test the alternative while your existing session still works.
Do not assume an email address alone will let you sign back in after removing social sign-in. Some services create an account around that identity link. Follow the provider's process for adding another method instead of creating an accidental duplicate account.
Save any files or work you need before changing a connection. Check where the actual data lives: in the original cloud account, on the third-party service or in both places. A sensitive-file sharing review can help separate original files from copies.
For an app you no longer need, you may prefer to export useful data and close the third-party account as well. That is a separate action from revoking permission.
Remove one connection and check the result
Use the identity provider's remove-access control for the specific connection. Read the warning and confirm. Then check the third-party service's own integration settings, because it may retain a disconnected account record or request reconnection.
Test the workflow that used the integration. A calendar booking form may stop checking availability; an automated report may stop updating. If the integration was shared, tell the people relying on it what changed.
Keep permission removal distinct from deleting an account. Google explicitly notes that stopping a sign-in link does not delete information on the other app. Data already copied needs its own retention or deletion review.
Use old-account clean-up when you want to end the relationship fully. Avoid assuming a single button reaches every database involved.
Watch for other access routes
An app may also use an API key, an app-specific password, a browser extension or a separate file-sharing link. Revoking one OAuth connection may not invalidate those independent routes.
Check the service's security page for tokens or keys you created, especially when experimenting with developer tools. Do not paste keys into a support chat or public issue to ask whether they still work. Revoke unused credentials from the account that issued them.
Browser extensions need a separate extension-permission review. Existing device sessions also deserve their own check. These are connected parts of account maintenance, not duplicates of the same action.
If you suspect misuse, preserve relevant event details and follow the provider's incident process. A suspicious integration needs more attention than an ordinary unused trial.
Keep a shorter list without constant maintenance
When trying a new service, make a note of the account connection and the purpose. A reminder in your existing project checklist can be enough to revisit it after the trial. You do not need a special subscription to keep track.
Prefer a small test folder or limited account where that is practical and permitted. Avoid using real client records to explore a new tool's capabilities. Read how to share less with AI services for a careful test workflow that also works for other cloud tools.
At the next review, keep the integrations you can explain, investigate the ones you cannot and remove the ones you no longer use. Every remaining permission should have a current reason to exist.
Sources and further reading
- Google: Manage links with other apps Consulted 28 September 2026.
- GitHub: Review authorized integrations Consulted 28 September 2026.
- Apple: Manage apps using Sign in with Apple Consulted 28 September 2026.
Consult the linked documentation for current details. Settings, availability and interface labels may change.
Spotted something that needs correcting? Send a correction with this article’s title and the relevant source.