Sistava

n8n Credentials Not Working? Fix OAuth and Auth Errors

How-to — — by Mahmoud Zalt

Redirect URI mismatches, callbacks that point at localhost, credentials that will not decrypt, and the n8n settings that quietly block a connection.

You are one connection away from a working automation. The workflow is built, the logic is right, and a node is sitting there in red because the account it needs will not attach.

Credentials are where two systems have to agree about something exactly, and exactly is a high bar. A trailing slash, a different subdomain or a port number that should not be there is enough for a provider to refuse the whole exchange.

One useful thing to know up front: n8n tests a credential when you finish creating it, to confirm it works. So a credential that saved cleanly was valid at that moment, which narrows the problem considerably when a node fails later.

Why does the provider reject the redirect URI?

Because the URL n8n actually sends during the OAuth exchange is not the string you registered in the provider's console. It has to match exactly, character for character, and the provider compares them literally rather than sensibly. A missing slash counts.

On self-hosted n8n the usual culprit is that n8n does not know its own public address, so it builds a callback pointing at localhost and port 5678. Nothing on the internet can reach that, and the provider will not accept it either. Set your public base URL through N8N_WEBHOOK_URL, along with N8N_PROTOCOL and N8N_HOST, then reopen the credential and copy the redirect URL n8n shows you after the change.

Copy it from the credential screen rather than typing it. Community threads on this problem are full of people who registered a URL that was correct in spirit and wrong in one character, and there is no error message that will point that out to you.

  1. Fix the base URL first — If n8n is showing a localhost or port 5678 callback, no amount of console configuration will help. Set the public base URL and restart before you touch the provider.
  2. Copy the redirect URL out of the n8n credential screen — Use the string n8n displays, exactly as displayed. Do not retype it and do not build it from a docs example.
  3. Paste it into the provider's console as an authorised redirect URI — In Google Cloud that is the OAuth client's authorised redirect URIs list. Other providers use their own wording for the same field.
  4. Save on the provider side and give it a moment — Some consoles take a short while to apply a change to a live OAuth client. If the first retry fails identically, wait and try once more before assuming the value is wrong.
  5. Reconnect from n8n and read the error, not the colour — A mismatch names the redirect URI. An access denied names scopes or consent. They are different problems and the message tells you which one you have.
  6. Confirm the credential saved and tested — n8n tests a credential on completion. If it saves without complaint, the connection worked at that moment and any later failure is a different fault.

Did an upgrade change how the OAuth callback works?

It might have. n8n's 2.0 breaking changes list includes N8N_SKIP_AUTH_ON_OAUTH_CALLBACK defaulting to false, which means authentication is now required on the OAuth callback where previously it could be skipped. If OAuth connections worked before an upgrade and stopped afterwards, put this on your list.

Separately, community reports describe self-hosted instances where the redirect URL inside an existing credential is fixed once generated, so changing your base URL later leaves old credentials pointing at the old address. That is a reported behaviour rather than documented design, and the practical workaround people describe is to recreate the affected credential after the base URL is correct.

If the authorisation itself completes and things still fail, the problem has moved inside n8n. There are three settings and one storage detail that stop a perfectly valid credential from doing anything useful, and none of them announce themselves in the node's error message.

Why can a saved credential fail to decrypt?

Because n8n is now using a different encryption key than the one that encrypted it. Community threads report a message stating that credentials could not be decrypted, and that the likely reason is that a different encryption key was used to encrypt the data. It shows up after a migration, a restore, or any move between instances.

The key lives in the n8n data directory, so it travels with the volume and not with the database. That is why a database-only backup restores every workflow and no credential. You can set the key deliberately through the N8N_ENCRYPTION_KEY environment variable, which is what you should do before moving anything, not after.

Queue mode makes this explicit. n8n's scaling documentation states that the encryption key of the main instance must be shared with all worker and webhook processor nodes, so a worker that starts without it cannot read a single credential your workflows depend on. The workflow will look fine and the worker will not be able to run it.

Is an n8n setting blocking the credential?

Two settings do this quietly. The first is the Allowed HTTP Request Domains field on the credential itself, which n8n documents with three levels: All lets the credential be used against any URL, Specific Domains restricts it to a list you supply, and None prevents it from being used in the HTTP Request node at all. If a credential works in its own node and refuses to appear in an HTTP Request node, check this first.

The second catches people who kept their secrets in environment variables. n8n 2.0 sets N8N_BLOCK_ENV_ACCESS_IN_NODE to true by default, which blocks the Code node from reading environment variables. A workflow that pulled an API key from the environment inside a Code node stops working at that upgrade, and the failure looks like a credential problem even though no credential is involved.

Every one of these is a reasonable design decision, and together they are why connecting a tool costs an afternoon rather than a minute. The connection layer is the part we deliberately took off the user at Sistava, because nobody hires help in order to spend their day in a developer console pasting callback URLs.

There is one more piece worth knowing if you run more than a single n8n instance, because credentials behave differently once workers enter the picture. It is a small detail with a large failure mode.

How do credential overwrites work across workers?

n8n supports credential overwrites through CREDENTIALS_OVERWRITE_DATA and a matching endpoint variable, which lets an operator supply values centrally rather than per user. Any of these variables can also be provided from a file by appending an underscore and FILE to the name, which keeps secrets out of your compose file.

The one to remember is CREDENTIALS_OVERWRITE_PERSISTENCE. n8n documents it as defaulting to false and as required for multi-instance or queue mode, because it is what propagates overwrites to workers. Leave it off in a queue setup and your main instance and your workers disagree about credentials, which produces failures that only appear under load.

What this will not fix

It will not fix a provider-side restriction. If an account lacks the permission, the plan tier or the API access the node needs, n8n will authorise successfully and then fail on the call itself. Read the message the provider returned rather than the node's summary, because the useful detail is usually inside it.

It also will not stop tokens expiring. Providers revoke and expire access under their own rules, and a credential that has worked for months can go quiet after a password change, an admin policy update or a scope revocation. Reconnecting is the fix, and knowing quickly is the real problem, which is an argument for an error workflow rather than a better credential.

And it will not reduce the count. Every tool you add is another connection to create, monitor and eventually repair, forever. That maintenance is the quiet tax on any automation stack, and it is why an assistant that arrives with its tools already connected, like the ones at Sistava, changes the shape of the work rather than just the speed of it.

Before you close this one out, write down which account each credential belongs to and who controls it. Most credential emergencies are really access emergencies, and they arrive on the day the person who created the OAuth client is on holiday or no longer works with you.

FAQ

Why does n8n show a redirect URL with localhost or port 5678?

Because n8n does not know its public address and is building the callback from its internal host and port. Set your public base URL with N8N_WEBHOOK_URL, along with N8N_PROTOCOL and N8N_HOST, then reopen the credential and copy the redirect URL n8n displays after the change. A provider will never accept a localhost callback for a hosted instance, so fixing this comes before anything you do in the provider's console.

How do I fix a redirect_uri_mismatch when connecting Google to n8n?

The redirect URI n8n sends must match the one registered in Google Cloud exactly, character for character. Copy the redirect URL from the n8n credential screen rather than typing it, and paste it into your OAuth client's authorised redirect URIs list. If n8n is showing a localhost address, fix your base URL settings first, because the value you register has to be the one n8n will actually send.

Why do my n8n credentials say they could not be decrypted?

Because the encryption key n8n is using now is not the one that encrypted them. The key lives in the n8n data directory rather than in the database, so a database-only backup restores workflows without the ability to read their credentials. Set the key deliberately with the N8N_ENCRYPTION_KEY environment variable before moving an instance. In queue mode, n8n documents that the main instance's key must be shared with all worker and webhook processor nodes.

Why can I not select a credential in the HTTP Request node?

Check the Allowed HTTP Request Domains field on the credential. n8n documents three levels: All allows the credential against any URL, Specific Domains restricts it to a comma separated list, and None prevents it from being used in the HTTP Request node at all. The setting exists to stop a credential being pointed at an unintended destination, so widen it deliberately rather than by habit.

Why did my Code node stop reading API keys from environment variables?

n8n 2.0 sets N8N_BLOCK_ENV_ACCESS_IN_NODE to true by default, which blocks the Code node from reading environment variables. Workflows that pulled a key from the environment inside a Code node stop working after that upgrade. The intended path is to store the secret as a credential rather than reading it from the process environment inside node code.

Does n8n check a credential when I save it?

Yes. n8n's documentation says that when you finish creating a credential, n8n tests it to confirm it works. That is useful for narrowing down later failures: if the credential saved cleanly, it authenticated successfully at that moment, so a failure a week later points at an expired or revoked token, a changed permission, or a setting that blocks its use rather than at the credential details themselves.

Sources