OAuth 2.0 Scope Builder: Build and Decode Permission Strings for Google, GitHub, and Stripe
Choosing the right OAuth 2.0 scopes is one of the most important security decisions in API integration. Requesting too many permissions makes users distrust your app and may violate platform policies. Requesting too few breaks features that need specific access.
Our OAuth Scope Builder lets you visually select scopes for Google, GitHub, and Stripe with clear risk indicators for each permission, then generates the exact scope string to use in your authorization URL.
OAuth scopes are passed as a space-separated string in the authorization URL:
Google OAuth Scope Categories
Identity scopes (openid, email, profile): Low risk, return basic user info
Drive scopes: Range from low (app-only files) to high (full file system access)
Gmail scopes: All medium to high risk - can read private emails and send on user's behalf
Calendar/Sheets scopes: Medium risk for read, high risk for write/full access
GitHub Scope Best Practices
For reading public repos: use public_repo instead of repo
For reading user data: use read:user instead of user
Never request delete_repo unless your app literally deletes repositories
For organization data: use read:org, not admin:org
Practical Examples
Google login only
- 1.Scopes: openid email profile
- 2.Risk: All low
- 3.Use case: Sign in with Google, show name and avatar
Google Drive backup app
- 1.Scopes: https://www.googleapis.com/auth/drive.file
- 2.Risk: Low (app files only)
- 3.Use case: Read and write only files your app creates
Frequently Asked Questions
What are OAuth 2.0 scopes?
OAuth 2.0 scopes define what permissions an application is requesting from the user. When a user authorizes your app, they grant access only to the specific resources listed in the scope parameter. For example, requesting only 'email' gives you the user's email address but not their files or calendar.
How do I use the generated scope string?
Add the scope string as the 'scope' query parameter in your OAuth authorization URL. For example: https://accounts.google.com/o/oauth2/auth?scope=openid%20email%20profile&.... URL-encode the string when adding it to a URL (spaces become %20).
What does the risk level mean?
Low risk scopes (green) access only basic profile data or read-only non-sensitive information. Medium risk (amber) scopes can read sensitive data or send actions on behalf of the user. High risk (red) scopes grant destructive or broad access like full file access, account deletion, or full API control.
Should I request the minimum scopes possible?
Yes, always follow the principle of least privilege. Request only the scopes your app actually needs. Requesting unnecessary scopes makes users less likely to authorize your app, may violate platform policies, and increases your security risk surface.
What is the difference between Google's drive and drive.readonly scopes?
drive.readonly lets your app read all files in the user's Google Drive. drive gives full read, write, create, and delete access to all files. Always prefer drive.readonly unless your app specifically needs to modify or delete files.
How do I decode an existing scope string?
Switch to the Decode tab, paste your scope string (space-separated), and the tool will identify each scope, show its risk level, and describe what access it grants. This is useful for auditing third-party apps you've authorized.
Are scopes standard across providers?
No. Each OAuth provider defines its own scope names. Google uses URL-format scopes (https://www.googleapis.com/auth/...). GitHub uses simple strings (repo, user:email). Stripe uses read_only / read_write. The OpenID Connect standard defines some common scopes (openid, email, profile) used across providers.
What is offline_access?
The offline_access scope requests a refresh token in addition to the access token. Refresh tokens allow your app to get new access tokens without prompting the user again. Without it, users must re-authorize when the access token expires (typically 1 hour).