What is an OAuth scope?

A scope is a string that tells the authorization server exactly which permissions an app is requesting, such as reading your email or posting on your behalf. The user sees these on the consent screen, and the issued access token is limited to the scopes granted.

How is the privacy risk scored?

Each scope is mapped to a tier: low for sign-in and public read, medium for reading your private data, high for modifying your account or data, and critical for full control, payments, or offline access. The overall risk for the request is the highest tier among all requested scopes.

Which providers are supported?

The bundled registry covers common scopes for Google, GitHub, Microsoft (Graph), Slack, Twitter/X, and Spotify. Unrecognised or provider-specific scopes are flagged as medium risk with a prompt to check the provider's documentation.

What is the offline_access scope?

offline_access grants the app a refresh token so it can obtain new access tokens without you being present. It is convenient for background sync but means the app retains access until you explicitly revoke it, so it is treated as a meaningful privacy consideration.

Is my scope string sent anywhere?

No. The scope registry is bundled into the page and all matching happens locally in your browser, so nothing you paste is transmitted or logged. You can safely analyse scopes from internal or pre-release apps.

OAuth 2.0 Scope Explainer & Risk Scorer

OAuth consent screens often list cryptic scope strings like https://www.googleapis.com/auth/gmail.send or repo without explaining what you are actually agreeing to. This tool decodes those scopes into plain English and scores how much access the app is requesting — so you can spot an app asking for far more than it needs.

How it works

Scopes are space, comma, or newline separated, so the tool splits your input into individual tokens and looks each one up in a bundled registry of common scopes for Google, GitHub, Microsoft, Slack, Twitter/X, and Spotify. Each known scope carries a plain-English description and a risk tier:

Low — identity and sign-in, or public read-only data (for example openid, read:user).
Medium — reading your private data (for example users:read, user-read-private).
High — modifying your account or content (for example Mail.Send, tweet.write).
Critical — full control, sensitive data, payments, or persistent offline access (for example repo, https://mail.google.com/, Files.ReadWrite.All).

The overall risk shown for the whole request is simply the highest tier among all the scopes — because an app with one critical scope has critical access regardless of how benign the others look. Unrecognised scopes are flagged so you know to verify them in the provider’s docs rather than assume they are safe.

Example

Pasting openid email profile https://www.googleapis.com/auth/gmail.send returns three low-risk sign-in scopes and one high-risk scope (send email on your behalf), so the overall request is rated High. That is a reasonable ask for a newsletter tool but a red flag for, say, a photo filter.

Notes and tips

The principle of least privilege applies to you as a user too: if an app wants repo (full read/write to all your code) when it only needs to read public repos, push back or deny it.
Granting a scope is reversible — revoke access from the provider’s security or connected-apps page, which also invalidates any refresh tokens.
Developers can use this to right-size their own consent screen: fewer and narrower scopes mean higher approval rates and less scary screens for users.