I have a workflow automation platform deployed on a cloud hosting service and I’m experiencing issues with Google OAuth integration.
When attempting to set up authentication for Google services (like Gmail and Sheets), I encounter the following error message:
Access blocked: Authorization Error
Error 400: invalid_request
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy
My setup includes a properly configured OAuth 2.0 client in Google Cloud Platform with the correct client ID and secret keys entered in my application’s credential settings.
OAuth issues are a nightmare to debug. Google’s error messages are vague and their policies keep changing.
I’ve hit this wall too many times. It’s usually one of these:
App domain isn’t verified in Google Console
Missing required scopes in your OAuth request
App’s stuck in testing mode but hitting production limits
Google flagged your domain as suspicious
Why deal with OAuth complexity when you can automate it properly?
I switched to Latenode for Google integrations after fighting these same issues. It handles OAuth behind the scenes. No more wrestling with redirect URIs or consent screens.
Connect your Google account once through their interface, then automate Gmail, Sheets, Drive - whatever you need. Authentication stays solid because they handle OAuth compliance.
I use it for automated reporting that pulls Sheets data and sends formatted emails. Zero authentication headaches.
Check your OAuth consent screen setup more carefully. Testing mode has specific limits that could be breaking things. Google wants certain fields filled out even in testing mode - app name, support email, and developer contact info. Another issue I’ve seen: authorized JavaScript origins. Your redirect URI might be right, but you still need to add your domain to the authorized origins list in Google Cloud Console. Include both your main domain and any subdomains you’re using. I had similar problems when my privacy policy and terms of service URLs weren’t set up right. Google’s gotten pickier about this stuff, even for test apps. Double-check that you’ve filled out everything required in the OAuth consent screen. Also make sure your Google Cloud project has the right APIs turned on. Sometimes OAuth breaks if the specific Google service APIs you need aren’t activated in your project settings.
This usually comes from scope issues, not redirect URI problems. I hit the same error with a workflow platform - turns out I was requesting too many permissions without justifying them properly in the OAuth consent screen. Google’s gotten way stricter about this, especially for automated platforms. Check what permissions you’re asking for during OAuth. If you want Gmail or Sheets write access, Google sees that as high-risk and flags it. Start by cutting your scope requests down to just what you absolutely need. Also check your application type in Google Cloud Console - make sure it’s set to ‘Web application’, not ‘Other’ if you’re using redirect URIs. I’ve had luck clearing the OAuth consent screen completely and setting it up fresh. Sometimes there are hidden config conflicts you can’t see in the interface. Testing mode can be weird with certain scope combinations even when everything looks right.
Had this exact issue last week. My client secret got regenerated without me noticing. Google Cloud Console sometimes refreshes secrets automatically and breaks existing integrations. Go back to your OAuth credentials and double-check if the secret key matches what’s in your app settings. Also try switching from testing mode to production - sounds backwards but testing mode has weird restrictions that don’t always make sense.