OAuth User Cap
An oauth user cap limits how many external accounts can sign into an unreviewed app. You clear this limit by marking the app internal or completing the provider review process. Teams often hit this wall when they roll out new internal tools across the company. To move fast, admins often grant broad scopes so one shared app works for everyone. Those wide roles let any signed-in user run risky commands against production systems. How an oauth user cap works in practice Identity providers put a
OAuth 2.0 + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An oauth user cap limits how many external accounts can sign into an unreviewed app. You clear this limit by marking the app internal or completing the provider review process. Teams often hit this wall when they roll out new internal tools across the company. To move fast, admins often grant broad scopes so one shared app works for everyone. Those wide roles let any signed-in user run risky commands against production systems.
How an oauth user cap works in practice
Identity providers put a strict limit on new apps that request sensitive user data. When a user logs in for the first time, the provider adds to a counter. Each unique consent screen approval counts toward the total quota for that project. Once the counter hits the oauth user cap, new users see a blocked login screen. Existing users who already gave consent can still log in and refresh their tokens. Revoking an old token does not lower the counter or free up a slot. The provider tracks lifetime unique grants rather than active sessions at any given moment.
Teams have two main ways to remove this ceiling in their identity provider console. If every user belongs to the same workspace domain, admins can mark the app internal. Internal apps skip the quota limit because only company accounts can log in. If contractors or customers outside the domain need to log in, the app stays external. For external apps, the team must submit the project for a formal provider review. The review team checks the requested scopes and the privacy rules before lifting the cap.
Why raising the quota requires tight scope design
Before you ask a provider to lift the cap, you should audit your scopes. Broad scopes slow down the provider review and create real risk for your backend systems. Many teams request full read and write permissions just to avoid login errors during testing. If ahundred users approve that wide scope, every one of them holds deep access. You should trim the app setup so it only asks for basic identity claims. When an app asks for minimal profile data, the provider review moves much faster. Keeping scopes narrow also shrinks the blast radius if an account gets compromised later.
What the native setup solves and what it leaves open
Managing your app quota and identity scopes solves the initial login problem. It proves who the user is and checks that they belong to your team. It also stops unknown external users from approving your app without a formal review. Still, this setup only governs the moment the user logs in to the app. Once the identity provider hands back a valid token, its job is done.
OAuth 2.0 + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The native login flow cannot see what the user does after the session starts. It does not inspect individual database queries, shell commands, or API calls in flight. A user who passes the login check might still run a destructive delete statement. They might also query a table full of customer emails, phone numbers, or card numbers. Static OAuth scopes are too coarse to block one bad query inside a valid session. They also cannot rewrite sensitive fields like national IDs in query results before returning data. Teams need controls that inspect each action and apply data masking during the live session.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does deleting a user account free up a slot under the cap?
No, removing a user or revoking their token does not lower the lifetime counter. You must either switch the app to internal mode or pass the provider review.
How can internal teams avoid hitting the oauth user cap?
Set the app visibility to internal within your identity provider settings. This setting removes the quota for anyone signing in with a company domain email.
Do service accounts count toward the user quota?
No, machine-to-machine flows do not show a user consent screen during login. The quota only tracks human users who click through the consent prompt for sensitive scopes.