OAuth token and integration inventory for agency client accounts

Audit and remove OAuth tokens and third-party integrations separately from user deletion. Deleting a user account often does not revoke app tokens or service-to-service integrations; you need a token-centric inventory, verification steps, and clear owners to ensure no hidden persistence remains after staff or vendor changes.

Why a token-centric workflow differs from mailbox-focused rotation

Mailbox-focused credential rotation targets mailbox passwords, SMTP/IMAP credentials, or mailbox delegation. Those steps are necessary but insufficient: OAuth tokens, API keys, and connected app grants can continue to operate independently of mailbox credentials. Decision boundary: stop when all active tokens and service connections associated with the departed user, team, or vendor are revoked or reassigned. Evidence limits: platform consoles and audit logs differ by provider; use official admin consoles and audit exports to locate tokens where possible.

Inventory: what to look for and where to find it

Scope the inventory by identity and by service. For each account, check OAuth app grants, service principals, API keys, delegated permissions, and provider-specific app registrations. Prioritize services used for sending email, accessing CRM/marketing systems, or administering DNS. Practical sequence: (1) list accounts and apps from your identity provider and SSO; (2) inspect third-party app grants in Google Workspace and Azure/Office 365 admin portals; (3) query SaaS apps' admin pages for connected apps and service accounts. For Google and Microsoft, use their admin consoles and audit documentation as directional references for where granting and revocation actions live 1.

Verification and isolation tests

After revocation, verify by testing each integration in a controlled way. Use a non-production recipient or monitoring mailbox and attempt the specific action the token enabled (API call, inbound webhook, or send attempt). Stop conditions: the action fails with an 'unauthorized' or 'invalid token' response, or the app no longer appears in the provider's active grants list. Decision boundary and evidence limits: Some providers delay revocation or cache tokens; if a test still succeeds immediately after revocation, document timestamps, retry after a short wait, and escalate to the vendor support channel as needed.

Owner map and handoff rules

Assign a single owner per integration (role: revoke, rotate, or reassign). Owners must have admin privileges in both the identity provider and the SaaS app or a documented escalation path. Practical sequence: record owner, required admin roles, and proof-of-revocation artifact (screenshot, audit log entry ID, or support ticket number).

Decision flow for revoked, rotated, or reattached tokens

If the integration is no longer required, revoke and record. If still required for ongoing services, rotate credentials and reattach to a service account or managed identity rather than a human user. If reattachment is needed but the app doesn't support managed identities, schedule a documented temporary access with an expiration and monitoring. Examples (labeled): Example — Move an OAuth client from a departed contractor’s user-owned app registration to a tenant-level app registration, then rotate its client secret and update the consuming service.

Record-keeping, audit artifacts, and retention

Store for each integration: integration name, type (OAuth/API key/webhook), owner, date revoked/rotated, proof artifact, and verification result. Retain artifacts according to your security policy; for investigations, keep at least one proof showing revocation and one verification test. Evidence limits: audit retention windows vary by provider, so export logs promptly when processing offboarding.

Practical checklist

• Export a list of users and service accounts from your identity provider and SSO.
• Query Google Workspace and Microsoft 365 admin consoles for OAuth app grants and service principals; export or screenshot grant lists 1.
• For each departed user, list all third-party apps they authorized or owned and tag as 'revoke', 'rotate', or 'reassign'.
• Revoke tokens for unused integrations; for required integrations, rotate credentials and attach to a managed service account.
• Run isolated verification tests for each revocation/rotation and capture the response and timestamps.
• Log owner, action taken, artifact (screenshot/log/ticket), and retention date in your offboarding tracker.
• If immediate revocation fails or tests succeed post-revocation, open a vendor support ticket and document the escalation.
• Schedule a follow-up permission audit and isolation test 7 and 30 days after offboarding.
• If an integration requires long-term continuity, set an expiration reminder and enforce periodic re-authorizations.

Where RepMail fits

Use this guide as an operational checklist during client offboarding and access audits in agency outreach workflows. When preparing or verifying client-integrated sending systems, run the token inventory and verification steps before concluding an offboarding or vendor change. Link the outcomes to your permissions audit, isolation tests, and standard offboarding record to avoid hidden persistence.

Continue with A/B Testing Cold Email With Small Samples for the next step in the workflow.

Related RepMail guides

• Agency knowledge transfer from departing account owner
• Agency permission matrix for client, contractor, and vendor roles

Sources