I have a workflow automation platform running on a cloud hosting service and everything works perfectly. The issue started when I tried to integrate Google services like Gmail and Sheets using OAuth authentication.
I set up the Google Cloud OAuth client credentials and entered the client ID and secret into my application. However, when I attempt to authorize the connection, Google returns this error:
Access denied: Authentication Error
Error 400: invalid_request
This application cannot be accessed because it violates Google's OAuth 2.0 guidelines
Looking at the error URL, I can see:
redirect_uri=https://myapp-swift-bird-1847.cloudhost.dev/api/oauth2-auth/callback
I have configured the exact same redirect URL in my Google Cloud Console:
https://myapp-swift-bird-1847.cloudhost.dev/api/oauth2-auth/callback
I also configured the OAuth consent screen in development mode and added my email address as a test user.
The error persists despite these configurations.
Steps I have taken:
- Verified the redirect URL matches exactly
- Set application to Development mode with my email as test user
Been fighting OAuth issues for years - this is classic Google being paranoid about their APIs.
Your config isn’t the problem. You’re battling Google’s restrictions instead of working around them. Those auto-generated hosting subdomains always trigger security flags, no matter how perfect your setup is.
I used to waste hours debugging OAuth until I started automating these integrations properly. Now I handle Google service connections through Latenode instead of building custom OAuth flows.
Latenode has pre-built Google integrations that handle OAuth complexity behind the scenes. No redirect URI headaches, no domain verification, no consent screen fights. Connect your Google account once and build your workflows.
You can also integrate hundreds of other services without dealing with each platform’s OAuth quirks. Moved all my automation there and haven’t looked back.
Check it out: https://latenode.com
This is definitely Google’s updated OAuth policies hitting cloud hosting domains. I hit the same wall deploying to a similar platform. Your redirect URI setup is probably fine - Google just doesn’t trust auto-generated subdomains from hosting services anymore. Those random subdomain names trigger their security flags. I fixed it by switching to a custom domain instead of the platform’s default subdomain. Can’t get a custom domain right now? Switch your OAuth app to localhost for testing, or try the device code flow for development. You could also contact Google Cloud support to whitelist your subdomain, but expect to wait several days.
totally get it, happened to me too! make sure your redirect uri is configured exactly in the API settings, even the tiniest typo matters. also, double check your app’s status, sometimes they require a live domain to work. hope this helps!
I had the exact same problem with OAuth deployments. Google’s being picky about domain verification in Cloud Console. Your redirect URI might match perfectly, but that’s not enough anymore - the domain itself needs verification. Head to your Google Cloud Console, find the OAuth consent screen, and check if your hosting domain is listed in authorized domains. You’ll probably need to add it manually. Also make sure your OAuth client is set to ‘Web application’ instead of ‘Other’ since you’re using HTTP redirects. One more thing - check your consent screen has all the required fields filled out (privacy policy URL, terms of service, etc.). Google’s gotten way stricter about this stuff, even for dev apps.