Topic 13 · Deep Dive

13.2 Managing Connected OAuth App and Persistent Token Risks

The Authorization-Code Grant in One Paragraph

When a third-party app says "Connect with provider," it sends your browser to the provider's authorization endpoint with its client ID, a redirect URI, a random state value, and a requested scope list. You authenticate and approve a consent screen; the provider redirects back with a short-lived authorization code, which the app's backend exchanges -- authenticated as that app -- for two tokens: a short-lived access token (often an hour, signed so the API can verify it offline) and a long-lived refresh token used to mint new access tokens silently, for months or indefinitely, with no password prompt and no second factor.

Scopes Are the Real Permission Boundary

The consent screen is the security contract. A todo app asking for full mail read-write, or "full account" instead of a single-folder scope, is a red flag: the token can only do what its scopes allow, so over-broad grants convert a minor app breach into a major account breach. Re-consent when you reinstall or re-link, and read the scope list again instead of clicking through.

Why Stale Tokens Keep Working

Access tokens are accepted based on signature and expiry alone. Revocation only propagates if the API consults a revocation list or if you revoke the refresh token at the provider. Many providers do not push revocation to third parties, and an app holding a valid refresh token keeps obtaining fresh access tokens even after the vendor is breached or abandons the product. "I deleted my account there" does not invalidate anything -- deletion of an app-side account rarely triggers a token revocation call.

CASB-Lite Hygiene for Individuals

Quarterly, open the connected-apps page, revoke anything unused or unrecognised, prefer re-authorized least-scope grants, and treat every grant as a standing credential equivalent to a password written down for that app.

Architecture Diagram

authorization-code grant and token life user third-party app auth server consent: scopes refresh token (app) code + tokens store silent renew stale token keeps working after breach
The app keeps a long-lived refresh token after one-time consent; unless you revoke it at the auth server, it renews indefinitely.

Key Takeaways

« Back to Topic 13« 13.1 / 13.3 »