"sign in with google temporarily disabled for this app" is the error screen that stops users cold when an OAuth client fails Google's security checks. Google's own OAuth documentation warns that apps requesting sensitive scopes can be blocked until verification or configuration issues are resolved, and developers regularly report this message appearing without any obvious change on their side.
The problem usually sits in one of three places: an unverified consent screen, a misconfigured redirect URI, or a policy violation flagged on the Google Cloud project. This guide walks through the five most common causes, the exact settings to check, and how to tell a temporary glitch apart from a permanent block so you can restore access quickly.
What the Error Actually Means
The message is a client-side rejection, not a server outage. Google's authorization server refuses to issue tokens because the app's OAuth configuration fails a policy or verification rule at the moment of sign-in.
Google's OAuth 2.0 Policies page states that apps using restricted or sensitive scopes must complete verification before they can be used by external users. Until that happens, only test users added to the project can authenticate.
Three signals usually trigger the block:
- The consent screen is still in "Testing" publishing status.
- A redirect URI in the request does not exactly match one registered in the console.
- The project was flagged for a scope that requires verification or a security assessment.
A common scenario is a developer who publishes an update adding a Gmail or Drive scope, then finds every non-test user locked out the next morning. Nothing "broke" — the app simply crossed into verification territory.
How to apply this: Open the Google Cloud Console, go to APIs & Services → OAuth consent screen, and note the publishing status before changing anything else.
The message is a client-side rejection, not a server outage; Google's authorization server refuses tokens because the app's OAuth configuration fails a policy or verification rule, so sign in with google temporarily disabled for this app reflects that refusal at the moment of request.
Because the authorization server withholds tokens rather than the app going down, seeing sign in with google temporarily disabled for this app points to configuration checks failing at request time, not an outage on Google's side.
Fix 1: Move the Consent Screen Out of Testing Mode
Testing mode is the single most frequent cause of this screen. Apps left in "Testing" only allow a limited set of manually added test users, and refresh tokens expire quickly.
Google's OAuth consent screen documentation explains that apps in testing status are capped at a small number of test users and are not available to the general public. If your users see the message, confirm the publishing status first.
To resolve it:
- Open the OAuth consent screen settings in the Cloud Console.
- Click Publish App if all required fields are complete.
- Fill in the privacy policy, homepage, and authorized domains — publishing fails silently if these are blank.
- Submit for verification if you use sensitive or restricted scopes.
If you only need internal use, switching the user type to Internal for a Workspace organization removes the public verification requirement entirely.
How to apply this: Compare your app's user type (Internal vs. External) against who actually needs to sign in, then publish or restrict accordingly.
Testing mode is the single most frequent cause of this screen, since apps left in "Testing" only allow a limited set of manually added test users and refresh tokens expire quickly; sign in with google temporarily disabled for this app often clears once the consent screen is moved to production.
If your app is still in testing with only manually added users, sign in with google temporarily disabled for this app will keep appearing for anyone outside that list, so publish the consent screen to resolve it.
Fix 2: Correct Redirect URI Mismatches
A single trailing slash can cause the failure. Google requires an exact string match between the redirect URI sent in the authorization request and one registered in the console.
The Google Identity documentation is explicit that redirect URIs must match exactly, including scheme, host, path, and trailing slash. Common mismatches include http versus https, localhost versus 127.0.0.1, and a missing /callback path segment.
Check these items in order:
- Authorized JavaScript origins versus redirect URIs — they are separate fields.
- Whether your app sends the URI from an environment variable that differs between staging and production.
- Whether a proxy or CDN rewrites the host header before the request reaches Google.
When "sign in with google temporarily disabled for this app" appears only on one environment, a redirect mismatch is the likely culprit. Compare the redirect_uri parameter in the failing request against the console list character by character.
How to apply this: Log the exact redirect_uri your app sends, then paste it into the console's authorized redirect URIs field to guarantee an identical match.
Fix 3: Address Scope and Verification Flags
Sensitive scopes trigger extra scrutiny. If your app requests Gmail, Drive, or Calendar data, Google may require verification, a privacy policy review, or a third-party security assessment.
The Google API Services User Data Policy requires apps to limit data access to what is necessary and to disclose how data is used. Apps that fail these requirements can be restricted, which surfaces as the disabled sign-in message.
Practical steps:
- Audit requested scopes in the Cloud Console and remove any you do not actively use.
- Add a clear privacy policy URL that explains data handling.
- Complete the verification form if you use restricted scopes.
Many teams find that dropping one unused scope moves the app back into the non-sensitive category and clears the block immediately.
How to apply this: List every scope your app requests, cross out the ones with no active feature behind them, and re-test sign-in after removing them.
Sensitive scopes trigger extra scrutiny, and if your app requests Gmail, Drive, or Calendar data, Google may require verification, a privacy policy review, or a third-party security assessment, which can leave sign in with google temporarily disabled for this app in place until flags are addressed.
Requests for sensitive scopes can stall approval, so sign in with google temporarily disabled for this app may persist until verification, a privacy policy review, or a security assessment is completed.
Fix 4: Check for Policy Violations and Project Suspensions
Sometimes the block is intentional. Google can suspend a project for policy violations, and the error looks identical to a configuration problem.
Review the OAuth consent screen page for warning banners and check the email tied to the project owner for notices from Google. A suspended client ID will fail every request until the issue is resolved through the appeals process described in the Google API Console Help.
Signs of a policy block:
- The error appears for all users, including test users.
- Other APIs in the same project also fail.
- You received an email about "unverified app" or "policy violation."
If you see "sign in with google temporarily disabled for this app" alongside a banner in the console, treat it as a compliance issue rather than a bug.
How to apply this: Search the project owner's inbox for messages from Google, then follow the appeal instructions before changing any code.
Fix 5: Rule Out Genuine Temporary Outages
Not every block is your fault. Google occasionally disables sign-in during incident response, and the message can appear fleet-wide for a short window.
Check the Google Workspace Status Dashboard before debugging your own setup. If there is an active incident affecting Google Identity, wait for resolution rather than changing configuration.
A comparison of the causes helps you triage fast:
| Symptom | Likely cause | Action to take |
|---|---|---|
| Only new users blocked | Testing mode | Publish the consent screen |
| One environment fails | Redirect URI mismatch | Match the URI exactly |
| All users blocked after update | New sensitive scope | Remove or verify the scope |
| Error plus console banner | Policy violation | Review email and appeal |
| Everyone blocked briefly | Google outage | Check the status dashboard |
How to apply this: Bookmark the status dashboard and check it first whenever "sign in with google temporarily disabled for this app" appears for multiple users at once.
Frequently Asked Questions About sign in with google temporarily disabled for this app
Why does this error appear only on mobile browsers?
Mobile browsers often block third-party cookies or use in-app webviews that Google no longer supports for OAuth. If your app opens the consent screen inside an embedded browser, switch to the system browser or a supported library.
Seeing "sign in with google temporarily disabled for this app" only on mobile usually points to a webview restriction rather than a server misconfiguration.
Can a free Google Cloud project hit this limit?
Yes. Free-tier projects are not exempt from verification rules, and quota or trust signals can differ from paid accounts. If your project is new and unverified, expect restrictions until you complete the consent screen details. The same "sign in with google temporarily disabled for this app" message can appear even when billing is enabled.
Does deleting and recreating the OAuth client help?
Rarely, and it can make things worse by invalidating existing tokens and user grants. Recreating a client resets its verification history, so you may wait longer for approval. Only recreate a client if the console shows it as deleted or corrupted, not as a first response to the sign-in block.
Rarely, and it can make things worse by invalidating existing tokens and user grants, so sign in with google temporarily disabled for this app usually is not fixed by deleting and recreating the OAuth client.
Recreating a client resets its verification history, so you may wait longer for approval while sign in with google temporarily disabled for this app continues to appear; only recreate a client if nothing else works.
How long does verification take once submitted?
Timing varies widely by scope sensitivity and completeness of your submission. Google does not publish a fixed timeline, and industry reports describe waits ranging from days to several weeks. During review, test users can often still sign in, so keep a small test group active while you wait for the block to lift.
Timing varies widely by scope sensitivity and completeness of your submission, and Google does not publish a fixed timeline, so sign in with google temporarily disabled for this app may linger during review.
Industry reports describe waits ranging from days to several weeks, and during that period sign in with google temporarily disabled for this app can remain visible to users until approval lands.
Is this the same as an "access blocked" authorization error?
They are related but distinct. "Access blocked" typically means the app failed verification outright, while the temporary disable message can also stem from configuration or outages. Both require checking the consent screen and redirect settings. Treat any sign-in with google temporarily disabled for this app report as a prompt to review the full OAuth configuration.
They are related but distinct: "Access blocked" typically means the app failed verification outright, while sign in with google temporarily disabled for this app can also stem from configuration or outages.
Both require checking your OAuth setup, so treat sign in with google temporarily disabled for this app as a symptom that may share causes with an "access blocked" authorization error.
Conclusion
The error almost always traces back to configuration or verification, not a random glitch. Keep these takeaways in mind:
- Check the consent screen publishing status before touching code.
- Match redirect URIs exactly, including trailing slashes.
- Trim unused sensitive scopes to avoid verification requirements.
- Confirm whether Google is having an outage before debugging further.
Each fix takes minutes once you know where to look, and most teams resolve the block the same day. Start with the Cloud Console consent screen, document what you changed, and re-test with a non-test user account.
If the sign in with google temporarily disabled for this app message persists after all five checks, open a support case with your project ID and the exact timestamp of the failure so Google can trace the request.
