OAuth Multiple Scopes
To request oauth multiple scopes, pass a space-separated list of permissions in your login request. The identity server reads this list and asks the user to approve each item. Teams use this approach so one token can work across several services. Still, bundling too many permissions into one token creates a large blast radius. If an attacker steals that token, they gain every permission inside it at once. How oauth multiple scopes work in a login flow In standard OAuth, a scope defines a boun
OAuth 2.0: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To request oauth multiple scopes, pass a space-separated list of permissions in your login request. The identity server reads this list and asks the user to approve each item. Teams use this approach so one token can work across several services. Still, bundling too many permissions into one token creates a large blast radius. If an attacker steals that token, they gain every permission inside it at once.
How oauth multiple scopes work in a login flow
In standard OAuth, a scope defines a boundary for what a token can do. An app often needs more than one boundary to finish a task. For example, a tool might need to read a calendar and send an email. Instead of running two separate login flows, the app combines these requests into one.
The app puts all needed scope strings into one parameter separated by spaces. When the user logs in, the provider shows a consent screen with every item. Once the user approves, the authorization server issues an access token. The server also returns a response showing which scopes it actually granted.
Sometimes a user unchecks an optional permission on the consent screen. Your app must check the returned list before it tries to run restricted calls. You should also map scopes to a specific resource server using audience claims. This stops a service with read rights from using that token on another API.
Token bloat and incremental consent
Asking for every possible scope at first login hurts user trust and security. Users hesitate when an app asks for full write rights right away. Security teams also dislike tokens that carry admin rights during basic read tasks. If a log file leaks that token, the attacker gets full admin control.
To fix this, teams use a pattern called incremental consent. The app starts by asking for only the basic login scope. When the user clicks a feature that needs write rights, the app asks again. This second call requests the new scope and merges it with existing permissions.
Even with incremental consent, putting many scopes in one token causes size problems. Identity providers often pack granted scopes directly into a JSON Web Token. When a user holds dozens of scopes, the token header grows too large. Web servers will reject HTTP requests when the header passes their size limit.
OAuth 2.0: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native scopes solve and where they fall short
Scopes do a great job of limiting what an app can do on paper. They let an API block a read-only token from making a delete call. They also give users a clear view of what data an app wants.
Still, scopes only check permissions at the front door of the service. Once a token passes that check, the scope cannot inspect the actual payload. A valid write scope lets an engineer or agent run a safe update. That exact same scope also lets them drop a table or wipe records.
Scopes also cannot filter sensitive fields out of a response in flight. If a scope grants read rights to a user table, it returns everything. The native token check will not mask emails, phone numbers, or card numbers. Scopes decide who gets in, not what individual queries or commands do next.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do you format oauth multiple scopes in a request?
You join the scope names into a single string separated by plain spaces. Inside a URL, those spaces get encoded as plus signs or percent-twenty characters. Never use commas or semicolons unless a non-standard provider says so.
Can a user approve only some of the requested scopes?
Yes, some identity servers let users uncheck optional items on the consent screen. The server then returns the final approved list alongside the new token. Your app should always read that response to see what was granted.
What happens if a requested scope does not exist?
Most providers will reject the entire login call and return an invalid scope error. A few providers simply ignore unknown strings and drop them from the token. Always test your scope strings against the provider settings before shipping to production.