OAuth2 Credential

Questions
1

Hi team,

I’m encountering a Google OAuth2 authentication error while connecting credentials for my calendar workflow in n8n.

When attempting to complete the OAuth consent screen flow, Google returns the following error message:

Access blocked: This app’s request is invalid

You can’t sign in because this app sent an invalid request. You can try again later, or contact the developer about this issue.

Has anyone run into this specific request is invalid block on Google OAuth2, or is it better practice to switch to a Service Account with Domain-Wide Delegation for background calendar automation?

Thanks for the help!

2

Hey @Marc2, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Myka, @Glorious, @Ugur_YL_Kayar - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

The most likely culprit is a Redirect URI mismatch. Google is very strict: the URL n8n sends in the request must exactly match the one you whitelisted in your Google Cloud Project.

  • Check the “Details” link: On the Google error page, there is often a small link or “Request Details” section. Click it. It will explicitly tell you which parameter is “invalid.” If it says redirect_uri_mismatch, you have found your problem.
  • Verify the Redirect URI:
    1. In n8n, open your Google Calendar credential and copy the OAuth Redirect URL provided in the credential configuration window.
    2. Go to the Google Cloud Console.
    3. Navigate to APIs & Services > Credentials.
    4. Find your OAuth 2.0 Client ID and click to edit it.
    5. Under Authorized redirect URIs, paste the exact URL you copied from n8n.
    6. Note: Ensure there are no trailing slashes or http vs https discrepancies.
  • Self-Hosted URL Configuration: If you are self-hosting n8n, ensure your environment variables N8N_EDITOR_BASE_URL and WEBHOOK_URL are set correctly to your public domain. If n8n thinks its URL is localhost:5678 but you are accessing it via n8n.yourdomain.com, the redirect URI sent to Google will be wrong.
  • OAuth Consent Screen Settings:
    • If your app is set to “External” and in “Testing” mode, you must add your email address to the “Test users” list in the Google Cloud Console (OAuth consent screen tab), or Google will block the request.

As for

  • If this is a personal project or a single-user tool, stick with OAuth2 and fix the Redirect URI.
  • If this is a production tool for a company that needs to manage various employees’ calendars automatically and unattended, switch to a Service Account with Domain-Wide Delegation.
4

Hi @Marc2
That route is closed for this node, which is also why the Service Account credential never took on your earlier attempt. n8n’s compatibility table marks Google Calendar as OAuth only with Service Account unsupported, so no key or delegation work makes it selectable there.
It is not the better practice either. Google advises against domain-wide delegation, because it permits impersonating any user in the domain including super admins.
If you do need unattended access to other people’s calendars, keep the service account and call the Calendar API from the HTTP Request node instead. Turn on “Set up for use in HTTP Request node” in the credential and add the calendar scope there.