Диагностика OAuth в n8n: callback URL, scopes и токены ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Ошибки OAuth в n8n чаще всего связаны не с самой нодой, а с несовпадением callback URL, домена за reverse proxy, scopes или прав пользователя во внешнем сервисе. При redirect_uri mismatch нужно скопировать OAuth Redirect URL прямо из credential n8n и добавить его в приложение провайдера. При 401 проверьте токен и refresh token, при 403 — scopes и права аккаунта на конкретный объект. После смены домена, HTTPS, proxy или N8N_ENCRYPTION_KEY старые credentials лучше проверять отдельно в тестовом workflow.

Как OAuth работает в n8n ¶

OAuth-сценарий в n8n состоит из трёх частей: credential в n8n, приложение у внешнего сервиса и redirect URL, по которому сервис возвращает пользователя после авторизации. Если хотя бы одна часть не совпадает, авторизация не завершится или токен будет получен, но нода не сможет выполнить действие.

Типичный поток такой:

В n8n создаётся credential.
n8n показывает OAuth Redirect URL.
Этот URL добавляется в приложение Google, Slack, HubSpot, Notion или другого сервиса.
Пользователь проходит авторизацию.
Сервис возвращает код авторизации в n8n.
n8n меняет код на access token и refresh token, если провайдер его выдаёт.
Нода использует credential в workflow.

Проблема возникает, когда внешний сервис ждёт один redirect URI, а n8n отправляет другой. Например, в приложении указан https://n8n.example.ru/rest/oauth2-credential/callback, а n8n за reverse proxy формирует URL с http, localhost, старым доменом или неправильным path.

Симптомы и вероятные причины ¶

Симптом	Что обычно означает	Где проверять
`redirect_uri mismatch`	Callback URL в приложении не совпадает с URL из n8n	Credential в n8n и настройки приложения
`401 Unauthorized`	Токен неверный, истёк, отозван или не передаётся	Credential, refresh token, заголовки запроса
`403 Forbidden`	Токен действительный, но прав не хватает	Scopes, роль пользователя, доступ к объекту
OAuth открывает localhost	n8n неправильно понимает внешний URL	`WEBHOOK_URL`, `N8N_EDITOR_BASE_URL`, proxy
Credential не сохраняется	Ошибка callback, cookies, HTTPS или шифрования	Логи n8n, домен, `N8N_ENCRYPTION_KEY`
Работало до переезда домена	Старый redirect URI остался у провайдера	Настройки OAuth app

Важно различать 401 и 403. 401 чаще говорит “я не узнаю этот токен”. 403 чаще говорит “токен узнаю, но действие запрещено”.

Исправление redirect_uri mismatch ¶

Не пытайтесь угадать callback URL по памяти. Правильный порядок такой:

Откройте нужный credential в n8n.
Скопируйте OAuth Redirect URL из интерфейса credential.
Откройте приложение у провайдера OAuth.
Вставьте URL в список разрешённых redirect URI.
Сохраните настройки приложения.
Вернитесь в n8n и заново пройдите авторизацию.

Если n8n показывает URL с localhost, http или старым доменом, сначала исправьте базовые URL самой установки. Для self-hosted n8n обычно проверяют:

N8N_HOST=n8n.example.ru
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.ru/
N8N_EDITOR_BASE_URL=https://n8n.example.ru/

После изменения .env пересоздайте контейнеры, иначе n8n может продолжать использовать старые значения:

docker compose up -d --force-recreate

Диагностика 401 Unauthorized ¶

401 появляется, когда внешний сервис не принимает авторизацию. Причины:

credential не прошёл OAuth до конца;
access token истёк, а refresh token не был получен или отозван;
приложение удалено или отключено у провайдера;
client secret изменился;
credential был перенесён без правильного N8N_ENCRYPTION_KEY;
workflow использует не тот credential.

Проверка:

Откройте credential и нажмите reconnect, если такая опция доступна.
Создайте отдельный тестовый workflow с одной нодой проблемного сервиса.
Выполните самый простой read-запрос, например получить профиль, список таблиц или список каналов.
Если тестовая нода падает, проблема в credential или правах, а не в основной логике workflow.
Если тестовая нода работает, ищите проблему в конкретном endpoint, payload или объекте.

Не вставляйте access token вручную в HTTP Request, если интеграция поддерживает credential. Иначе токен быстро окажется в execution data или экспортированном workflow.

Диагностика 403 Forbidden ¶

403 означает, что авторизация есть, но действие запрещено. Самые частые причины:

не хватает scope read, write, offline_access или специализированного scope;
пользователь авторизовал приложение не тем аккаунтом;
у аккаунта нет доступа к нужному workspace, таблице, каналу, проекту или CRM-сущности;
приложение находится в test mode и не разрешает доступ внешнему пользователю;
организация запрещает сторонние OAuth apps;
endpoint требует admin-роль, а credential создан от обычного пользователя.

Исправление начинается не с пересоздания workflow, а с карты доступа: какое действие выполняет нода, какой scope нужен, какой пользователь авторизован, есть ли у него доступ к объекту.

Пример: workflow читает Google Sheet. Credential может быть рабочим, OAuth успешным, но 403 появится, если конкретная таблица не расшарена на пользователя, который прошёл OAuth.

После смены домена или reverse proxy ¶

OAuth особенно чувствителен к внешнему URL. После переезда с http://ip:5678 на https://n8n.example.ru старые credentials могут продолжать ссылаться на прежний redirect URI у провайдера. План миграции:

Настройте HTTPS и базовые URL n8n.
Проверьте, какой OAuth Redirect URL показывает credential.
Обновите redirect URI во внешних приложениях.
Переподключите credentials.
Прогоните тестовые workflow.
Только после этого переключайте production workflow.

Если используется несколько окружений — dev, staging, production — заводите разные OAuth apps или явно разделяйте redirect URI. Не смешивайте localhost, staging и production в одном credential без необходимости.

Что записывать в журнал ошибки ¶

Для OAuth-ошибок полезно сохранять не только текст ошибки, но и контекст:

название credential;
сервис и endpoint;
HTTP status;
workflow name и execution ID;
какой пользователь проходил OAuth;
какие scopes выданы;
какой redirect URI указан у провайдера;
менялся ли домен, proxy, HTTPS или N8N_ENCRYPTION_KEY.

Такой журнал позволяет отличить ошибку инфраструктуры от ошибки прав. Без него команда часто тратит часы на пересоздание credentials, хотя проблема в одном missing scope.

Чего не делать ¶

Не добавляйте “все возможные scopes”, если нужен один read-only доступ. Не используйте личный админский аккаунт для постоянной автоматизации. Не храните refresh token в Set node. Не отправляйте скриншоты credentials с client secret. Не меняйте одновременно домен, proxy, OAuth app и workflow: исправляйте по одной причине за раз.

FAQ ¶

Где взять правильный redirect URI для OAuth?
В интерфейсе n8n внутри конкретного credential. Его нужно скопировать и вставить в настройки OAuth-приложения у провайдера.

Почему n8n показывает localhost в OAuth URL?
Обычно не настроены внешний домен, WEBHOOK_URL, N8N_EDITOR_BASE_URL или reverse proxy передаёт неправильные headers.

Почему после успешной авторизации нода получает 403?
OAuth прошёл, но выданных прав недостаточно для конкретного действия или у пользователя нет доступа к нужному объекту.

Нужно ли пересоздавать credential после смены домена?
Часто да. Сначала обновите redirect URI у провайдера, затем переподключите credential в n8n и проверьте его в тестовом workflow.

Может ли N8N_ENCRYPTION_KEY сломать credentials?
Да. Если ключ изменён или потерян после переноса, n8n может не расшифровать сохранённые credentials.