OAuth Scope Analyzer

Analyzing OAuth 2.0 Scopes for Least-Privilege Violations

OAuth 2.0 scopes control what permissions an application requests from a user or service. Over-scoped tokens — requesting admin access when read-only suffices, or requesting write+delete when only write is needed — violate the principle of least privilege and increase the blast radius of token compromise. The OAuth Scope Analyzer examines your scope lists against provider-specific knowledge bases to detect over-permission patterns, dangerous scope combinations, and scope creep that accumulates as applications evolve.

Paste your OAuth scopes (space or comma separated) and select the provider (GitHub, Google, Azure AD, or Okta) to receive a detailed analysis of permission levels, dangerous combinations, and least-privilege alternatives for each overly broad scope. All processing happens entirely in your browser — your scope configurations never leave your device.

Over-Permission Detection

The analyzer identifies scopes that grant more access than typically needed:

• Admin when read suffices: repo (full access) when repo:status or public_repo would work
• Write when read suffices: user:email grants read, but user grants read+write to profile
• Broad access to specific need: https://www.googleapis.com/auth/drive (full Drive) when drive.file (only app-created files) suffices
• Wildcard scopes: Scopes like * or all that grant unrestricted access

For each over-permission, the analyzer suggests the narrowest scope that still enables the intended functionality.

Dangerous Scope Combinations

Some scope combinations create compound risks greater than individual scopes suggest:

• Read + Delete: A compromised token with both read and delete access enables data exfiltration followed by evidence destruction
• User impersonation + API access: Combined scopes that allow acting as any user while accessing sensitive APIs
• Admin + No MFA requirement: Administrative scopes without additional authentication factors create single-point-of-failure risks
• Cross-service escalation: Scopes spanning multiple services that together enable lateral movement

Provider-Specific Analysis

Each OAuth provider has unique scope semantics and hierarchies:

• GitHub: repo includes all sub-scopes (status, deployment, public_repo), admin:org grants organization management
• Google: URL-based scopes with varying granularity (drive vs drive.file, gmail.readonly vs gmail.compose)
• Azure AD: Application vs delegated permissions with different consent requirements and admin consent flows
• Okta: Custom scopes with claim-based access tokens and authorization server policies

The analyzer understands provider-specific scope hierarchies to detect implicit permissions granted by broad scopes that include narrower ones. For GitHub, requesting repo implicitly includes repo:status, repo_deployment, and public_repo — the analyzer detects when these implicit grants exceed the application's actual needs. For Google APIs, the analyzer maps URL-format scopes to their human-readable equivalents and identifies when restricted scopes (requiring app verification) are used unnecessarily.

Token Lifecycle and Scope Reduction

The analyzer also evaluates scope configurations against token lifecycle best practices:

• Refresh token scope inheritance: Refresh tokens inheriting overly broad scopes persist elevated access beyond the original session
• Incremental authorization: Requesting all scopes upfront rather than incrementally as features are used increases risk exposure from day one
• Scope reduction on renewal: Token refresh operations that could request narrower scopes but default to the original broad set
• Short-lived vs long-lived tokens: Broad scopes on tokens with extended expiration create persistent attack surfaces

Best practice is to request the minimum scopes required for the current user action and expand incrementally when additional permissions are needed. The analyzer provides a suggested timeline of which scopes to request at each stage of user interaction.

Code Examples

GitHub OAuth Scope Analysis

# Input scopes:
repo admin:org user delete_repo workflow

# Analysis:
# - CRITICAL: "delete_repo" — allows permanent repository deletion
# - HIGH: "admin:org" — full organization management (members, teams, settings)
# - WARN: "repo" — grants write to all repositories; consider "public_repo" or "repo:status"
# - WARN: "workflow" — allows modifying GitHub Actions (supply chain risk)
# - INFO: "user" — includes user:email implicitly

# Recommendations:
# If app only reads CI status: Replace "repo" with "repo:status"
# If app only needs org membership: Replace "admin:org" with "read:org"
# If app never deletes repos: Remove "delete_repo"
# Security score: 3/10 (over-permissioned)