--- title: "OAuth Scopes — Identity Glossary | IDSync" description: "OAuth scopes are strings (like 'read:users' or 'mail.send') that a client requests at authorization time and that the resource server uses to enforce least…" lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://idsync.com/" }, { "@type": "ListItem", "position": 2, "name": "Glossary", "item": "https://idsync.com/glossary" }, { "@type": "ListItem", "position": 3, "name": "OAuth Scopes", "item": "https://idsync.com/glossary/oauth-scopes" } ] }, { "@context": "https://schema.org", "@type": "DefinedTerm", "@id": "https://idsync.com/glossary/oauth-scopes", "name": "OAuth Scopes", "alternateName": [ "Scopes", "OAuth Scopes" ], "description": "OAuth scopes are strings (like 'read:users' or 'mail.send') that a client requests at authorization time and that the resource server uses to enforce least privilege — they declare *what* an access token is allowed to do, not *who* the user is.", "url": "https://idsync.com/glossary/oauth-scopes", "inDefinedTermSet": "https://idsync.com/glossary" } ] --- [![IDSync — identity software buyer platform](/assets/idsync-logo-BKS89EW4.png)](/) [Directory](/directory) [Compare](/compare) [Resources](/resources) [Browse tools](/directory)[Run Stack Finder](/stack-finder) 1. [Home](/) 2. [Glossary](/glossary) 3. OAuth Scopes Standards # OAuth Scopes OAuth scopes are strings (like 'read:users' or 'mail.send') that a client requests at authorization time and that the resource server uses to enforce least privilege — they declare \*what\* an access token is allowed to do, not \*who\* the user is. Last reviewed 3 months ago Key points - Scopes are coarse-grained capabilities; the resource server is the authority on what each scope means. - Display scopes on the consent screen so users see what they're approving (the Google / GitHub consent UX). - Request the minimum scopes your app needs — every excess scope is excess blast radius if a token leaks. - OIDC reserves: openid (required), profile, email, address, phone, offline\_access. - Scopes ≠ permissions — fine-grained authorization (which row, which tenant) belongs in claims or a policy engine, not scopes. ## What are OAuth scopes? **Scopes** are the strings an OAuth 2.0 client asks for at authorization time to declare what it intends to do with the resulting access token. `read:repo`, `write:user`, `mail.send`, `https://www.googleapis.com/auth/drive.readonly` — these are all scopes. The authorization server displays them on the consent screen ("This app wants to read your repos and send email as you"). If the user approves, the access token is minted with those scopes embedded, and the resource server enforces them on every API call. ## How they're used 1. Client requests an authorization URL with `scope=openid profile email https://api.acme.com/invoices.read`. 2. User consents (or admin pre-consents for workforce apps). 3. Token endpoint returns an access token whose `scope` claim contains the granted scopes (possibly a subset of what was requested). 4. Resource server checks: does this token have the scope required for this endpoint? ## Scopes vs permissions vs roles A common mistake is to treat scopes as a fine-grained permission system. They aren't. | | Scopes | App-level permissions | | --- | --- | --- | | Granularity | Coarse (read vs write, by resource type) | Fine (which document, which row, which tenant) | | Authority | Authorization server + resource server | Application + policy engine | | Audience | The user (consent screen) and the API | Internal RBAC/ABAC | For real authorization, combine **scopes** (what kind of action) with **claims** (sub, tenant, roles) and a **policy engine** (RBAC/ABAC/ReBAC). ## Best practices - **Least privilege** — request the smallest set of scopes. Don't ask for `admin` if `read:profile` works. - **Incremental authorization** — ask for advanced scopes only when the user reaches the feature that needs them. - **Document scopes clearly** in your developer portal — what each one grants, examples, recovery if revoked. - **Map scopes to API endpoints** with middleware, not ad-hoc `if` statements. ## Editorial note If your API has 50 scopes, you're probably trying to encode app-level permissions in OAuth — move that into your authorization layer (Cedar, OPA, Oso) and keep scopes coarse. ## Standards & references - [RFC 6749 §3.3 — Access Token Scope](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) IDSync provides educational buyer guidance based on publicly available information, editorial review, and user-submitted data. Vendor information should be verified before purchase. [Who we are, our methodology & disclosure policy](/about). ### One identity concept, explained per issue Get vendor-neutral identity explainers and market updates in your inbox. Work email\* Name Company Role (optional) Interests (optional) Pick what you want more of. IAMCIAMSSO/MFAIGA/PAMSCIM/provisioningAI agent identityVendor updatesSecurity incidents Subscribe Twice-monthly identity digest. Curated, vendor-neutral. Unsubscribe any time. ### Vendor categories [authorization](/directory/category/authorization)[api security](/directory/category/api-security) ### Related terms [oauth 2](/glossary/oauth-2)[openid connect](/glossary/openid-connect)[access token](/glossary/access-token) ### Not sure which tool you need? Run the IAM Stack Finder for a vendor-neutral shortlist tailored to your stack. [Run the Stack Finder](/stack-finder) ### Explore tools for this topic Browse vetted vendors in the authorization category. [Explore tools](/directory/category/authorization) [![IDSync home](/assets/idsync-logo-BKS89EW4.png)](/) The buyer-focused platform for identity, access, and authentication software. #### Platform - [Home](/) - [IAM Stack Finder](/stack-finder) - [Directory](/directory) - [Resources](/resources) - [State of AI Agent Identity 2026](/reports/state-of-ai-agent-identity-2026) - [Buyer Guides](/guides) - [Glossary](/glossary) - [Newsletter](/newsletter) - [Newsletter Archive](/newsletter/archive) #### Best of guides - [All comparisons](/compare) - [All vendor alternatives](/alternatives) - [Best SSO tools](/compare/best-sso-tools) - [Best MFA tools](/compare/best-mfa-tools) - [Best PAM tools](/compare/best-pam-tools) - [Best IGA tools](/compare/best-iga-tools) - [Best CIAM tools](/compare/best-ciam-tools) - [Best passwordless auth](/compare/best-passwordless-authentication-tools) - [Best identity security](/compare/best-identity-security-tools) - [Best machine identity](/compare/best-machine-identity-tools) - [Best SaaS access governance](/compare/best-saas-access-governance-tools) - [Best developer auth](/compare/best-developer-authentication-tools) - [Best for startups](/compare/best-iam-tools-for-startups) - [Best for enterprises](/compare/best-iam-tools-for-enterprises) - [Best SCIM tools](/compare/best-scim-provisioning-tools) - [Best for AI agents](/compare/best-ai-agent-identity-tools) - [Best NHI tools](/compare/best-nhi-management-tools) - [Okta pricing explained](/guides/okta-pricing) - [Auth0 pricing explained](/guides/auth0-pricing) - [Okta alternatives](/alternatives/okta) - [Auth0 alternatives](/alternatives/auth0) #### For Vendors - [Sponsor](/sponsor) - [Badges](/badges) - [Submit Product](/submit-product) - [Claim Profile](/claim-profile) - [Partner](/partner) #### Company - [About & Methodology](/about) - [Contact](/contact) - [Privacy](/privacy) Vendor names, logos, and trademarks are the property of their respective owners. IDSync is an independent buyer resource and does not imply endorsement unless explicitly stated. Logos are displayed for identification purposes only. IDSync (idsync.com) is operated by TetraCore, Bowling Green, Ohio. It is not affiliated with the IDSync® Active Directory synchronizer by Identity Syncronizer — [learn more](/about#idsync-disambiguation). © 2026 IDSync. All rights reserved. Editorial independence. Sponsored placements are clearly disclosed.