Reconcile Provider Access After Revocation

An application may mark a connection revoked while the third-party provider still lists an active grant. The reverse can also happen: the provider revokes a token, but the application UI continues to show it as ready. Reconciliation compares both systems and records the difference.

List the authoritative provider objects for the integration: OAuth grants, API keys, service accounts, roles, and active sessions as supported. Match them to local records using stable IDs, not display names or token values. OWASP's authorization and secrets guidance supports current grants and lifecycle control, but the provider is the authority for its own credential status.

Provider-local diff

A local revoked flag may stop your application but does not necessarily stop a copied key used directly with the provider. Do not describe it as provider revocation until the provider confirms. Conversely, a provider outage should not cause the app to assume a grant is active.

Reconciliation run

Use an owned test account with one approved connection. Revoke it locally and check the provider listing. If the provider requires a separate revoke call, verify that call and its result. Then revoke a second test grant directly at the provider and confirm the local UI and jobs stop claiming access. Include an expired grant and an unknown status as separate cases.

Record IDs, times, API response classes, and the operator's decision without raw tokens. Where the provider offers no listing or revocation status, document the evidence limit and choose a safe test or expiry policy. Keep discrepancies visible until resolved; do not make the dashboard green by deleting the local row. Treat provider state as authoritative when the local register disagrees; investigate the mismatch before closing it.