Access Blocked: Google Verification and Self-Hosted n8n Credentials

This error means Google is blocking the OAuth consent screen because the application requesting access has not completed Google’s verification review for the scopes it is asking for. It is not a bug in n8n or in your workflow. The fastest fix is to use your own Google Cloud OAuth client, which puts you in control of the consent screen entirely.

The error is confusing because it names an application you did not create and a verification process you cannot influence. Understanding which party owns which piece makes the fix obvious, and the fix happens to be the right architecture anyway.

Table of contents

• What Google is actually blocking
• The immediate fix: add yourself as a test user
• Using your own OAuth client, which is the real fix
• Making the redirect URI work at all
• When to use a service account instead
• Keeping the credentials working
• How this fits the rest of the stack
• FAQ

What Google is actually blocking

When a workflow connects to Google Drive, Sheets, or Gmail, an OAuth flow runs. That flow identifies a client application by its client ID, and Google checks that application’s verification status against the scopes requested.

Google splits scopes into tiers, and the tier decides how strict the check is:

• Non-sensitive — basic profile and email. No review required.
• Sensitive — Drive, Sheets, Calendar, Contacts. Requires verification for public use.
• Restricted — Gmail message content, full Drive access. Requires verification plus an annual third-party security assessment.

Restricted scopes are the ones that cause this most often, because Gmail access falls there and the security-assessment requirement makes verification genuinely expensive.

So the error is Google saying: this client is asking for sensitive access and has not been approved to ask the general public for it.

The immediate fix: add yourself as a test user

An unverified OAuth app can still be used by up to 100 explicitly-listed test users. If you control the Google Cloud project, this takes two minutes.

1. Open the Google Cloud Console and select the project holding your OAuth client.
2. Go to APIs & Services → OAuth consent screen.
3. With the publishing status set to Testing, find the Test users section.
4. Add the Google account you are connecting, then retry the connection in n8n.

You will still see an unverified-app warning. Click Advanced, then Go to [app name] (unsafe) to proceed. That warning is expected and correct — Google is telling you it has not vetted this application, which is true and fine when the application is yours.

Test-mode refresh tokens expire after 7 days. This is the detail that catches people: everything works, then the connection silently breaks a week later. For anything running on a schedule, publish the app rather than leaving it in testing.

Publishing an internal-use app that only your own Google Workspace accounts will use does not require verification if you set the user type to Internal — available when the project belongs to a Workspace organisation. That is the clean answer for company use.

Using your own OAuth client, which is the real fix

If you are connecting through a shared client owned by someone else, you are dependent on their verification status. Creating your own removes that dependency entirely and is not difficult.

1. In Google Cloud Console, create a project (or use an existing one).
2. APIs & Services → Library — enable the specific APIs you need: Google Drive API, Google Sheets API, Gmail API.
3. OAuth consent screen — choose Internal if you have a Workspace organisation, External otherwise. Fill in the app name, support email, and developer contact.
4. Add only the scopes you actually need. Every extra scope raises the verification bar.
5. Credentials → Create Credentials → OAuth client ID → Web application.
6. Add the redirect URI that n8n shows you on the credential screen.
7. Copy the client ID and secret into the n8n credential.

The redirect URI must match exactly — protocol, host, port, path, and no trailing slash difference. A mismatch produces redirect_uri_mismatch, which is a different error with the same feeling.

# Self-hosted n8n redirect URI shape
https://n8n.yourdomain.com/rest/oauth2-credential/callback

# This must be reachable over HTTPS from a browser and
# registered verbatim in the Google Cloud credential.

Request the narrowest scope that works. drive.file — access only to files the app created or the user explicitly opened — is sensitive rather than restricted, and avoids the security assessment that full drive triggers. For many workflows it is sufficient and nobody checks.

Making the redirect URI work at all

Google requires HTTPS for OAuth redirect URIs, with an exception for localhost. A self-hosted n8n on a bare IP address or plain HTTP cannot complete the flow.

Three settings have to agree, and disagreement is the most common cause of an OAuth loop that never completes:

# n8n must know its own public URL
N8N_HOST=n8n.yourdomain.com
N8N_PROTOCOL=https
N8N_PORT=443
WEBHOOK_URL=https://n8n.yourdomain.com/

# Behind a reverse proxy or platform TLS termination
N8N_PROXY_HOPS=1

If WEBHOOK_URL is wrong, n8n generates a redirect URI that does not match what you registered, and no amount of correcting the Google side fixes it.

This is one of the places where a managed deployment removes a whole category of problem. On RunxBuild, n8n runs as a managed tool with a custom domain and certificate handled by the platform, so the HTTPS requirement and the public URL are settled before you start the OAuth flow rather than during it. n8n on a $6 Basic plan with a managed Postgres alongside it is the usual shape — the custom domains documentation covers the domain and certificate side.

When to use a service account instead

OAuth is for acting on behalf of a human. If your workflow is a machine acting on its own — writing to a Sheet the company owns, dropping files in a shared Drive folder — a service account is the better fit and sidesteps consent screens entirely.

1. Create a service account in the Google Cloud project.
2. Generate a JSON key and store it in the n8n credential.
3. Share the target Sheet or Drive folder with the service account’s email address, exactly as you would with a colleague.
4. Select the service account authentication method on the n8n node.

No consent screen, no verification, no 7-day token expiry. The credential does not belong to a person, which also means it survives that person leaving.

• Works for: Sheets, Drive, Calendar, BigQuery, Cloud Storage — anything where resources can be shared with an address.
• Does not work for: Gmail on a consumer account. Sending mail as a Workspace user requires domain-wide delegation, configured by a Workspace admin.
• Watch: service account Drive storage is separate and limited. Files it creates belong to it, so create them in a shared drive or transfer ownership.

For scheduled automation against company resources, a service account is almost always the correct choice and the OAuth question never arises.

Keeping the credentials working

• Publish the app rather than leaving it in testing, or refresh tokens expire every 7 days.
• Watch for revocation. Changing a Google password, an admin revoking third-party access, or 6 months of inactivity all invalidate refresh tokens.
• Store the encryption key. n8n encrypts credentials with N8N_ENCRYPTION_KEY; lose it and every stored credential must be re-entered. Set it explicitly rather than letting n8n generate one you never recorded.
• Use Postgres, not SQLite. Credentials and execution history live in n8n’s database, and SQLite is a poor place for anything you would be upset to lose.

# Set this yourself and back it up. Do not let it be generated.
N8N_ENCRYPTION_KEY=<a long random string you have stored securely>

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=your-db-host
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=<from environment, not from a file in the repo>

Losing N8N_ENCRYPTION_KEY is unrecoverable. Every credential in the instance becomes undecryptable and must be re-created by hand. It belongs in your password manager on the day you set it up, not the day you need it.

How this fits the rest of the stack

The error means an unverified OAuth client is requesting sensitive scopes. Add yourself as a test user for an immediate fix, create your own Google Cloud OAuth client so verification status is yours to control, and use a service account when the workflow is a machine acting on company resources rather than on a person’s behalf. If you are pricing self-hosted n8n with a proper database and a real domain, the RunxBuild hosting calculator shows the tool plan and database separately.

Useful related references:

• The Transfer Has Triggered a Web Application Firewall: How to Unblock It
• There Has Been a Critical Error on This Website: Finding What WordPress Is Hiding
• link to domain: The Three Layers Every Custom Domain Has and the Order to Wire Them
• Services on RunxBuild

FAQ

What does access blocked has not completed the Google verification process mean?

Google is blocking the OAuth consent screen because the client application requesting access has not passed Google’s review for the sensitive or restricted scopes it is asking for. It is a Google policy check, not an n8n bug.

How do I fix it immediately?

Add your Google account as a test user under APIs & Services, OAuth consent screen in the Google Cloud project that owns the client, then retry. You will see an unverified-app warning; proceed via Advanced.

Why does my Google credential stop working after a week?

OAuth apps in Testing status issue refresh tokens that expire after 7 days. Publish the app, or set the user type to Internal if the project belongs to a Google Workspace organisation.

Should I use a service account instead of OAuth?

Yes, when the workflow acts on its own rather than on behalf of a person. Share the target Sheet or Drive folder with the service account’s email and there is no consent screen, no verification, and no token expiry.

Why does my self-hosted n8n OAuth redirect fail?

Google requires HTTPS redirect URIs and the URI must match exactly. Check that N8N_HOST, N8N_PROTOCOL, and WEBHOOK_URL reflect your real public URL — if they are wrong, n8n generates a redirect that does not match what you registered.