Reduce Third-Party OAuth Scopes

A third-party integration may ask for every scope in a provider's catalog because it is easier than mapping features. That leaves a token with access the product does not use. Scope reduction starts with actual API calls and ends with a consent and rollout plan; deleting text from a consent screen is not enough.

OWASP's OAuth guidance emphasizes scope restriction and proper token handling. List the provider scopes, the endpoints they unlock, and the user-facing feature that needs each one. Mark scopes that are only used by old code or an inactive experiment.

Scope-to-feature map

The rows are a worksheet example, not a claim about any provider. Providers may combine permissions or require a broader scope for one endpoint. Document that constraint rather than claiming least privilege where it is unavailable. Check existing refresh tokens and grants; a new requested-scope list may not automatically shrink tokens already issued.

Reconsent plan

In an owned test account, authorize with the reduced set and complete each supported feature. Try a removed endpoint and require an auth denial. Then test an existing user's grant after deployment. Decide whether to revoke and reauthorize it, let it expire, or migrate it under provider rules. Explain any new consent request in plain language.

Record provider scope names, app version, feature tests, and grant status without token values. Verify the third-party provider shows the expected permissions where its UI or API permits inspection. If a feature needs a new scope later, request it at that feature's entry point rather than at initial sign-in. A narrow OAuth token still needs current user, tenant, and resource authorization in the application.