OAuth production checklist n8n: проверка перед запуском ¶

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

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

OAuth в n8n ломается в production чаще всего из-за несовпадения redirect URI, неверного публичного URL, лишних или недостающих scopes, личного владельца приложения и отсутствия плана reauth. Перед запуском проверьте OAuth Callback/Redirect URL из n8n, настройки reverse proxy, consent screen, права приложения, владельца credential, refresh token и smoke tests для read/write-действий.

Чем OAuth опасен в production ¶

API key обычно можно заменить быстро. OAuth credential зависит от приложения у провайдера, redirect URI, scopes, consent screen, токенов, владельца аккаунта и политики безопасности сервиса. Ошибка может проявиться не сразу: workflow работает месяц, а потом token отзывается, пользователь теряет доступ, провайдер меняет правила, или новый домен ломает callback.

Production-чеклист нужен до того, как workflow станет частью продаж, поддержки, отчётов или платежной цепочки.

1. Проверить callback/redirect URL ¶

В большинстве OAuth-интеграций нужно взять OAuth Redirect URL или Callback URL из n8n credential и добавить его в приложение у провайдера. Не набирайте URL вручную, если его можно скопировать из n8n.

Проверьте:

• домен совпадает с production-доменом n8n;
• используется https, а не локальный http://localhost:5678;
• путь callback не изменён reverse proxy;
• нет лишнего slash, другого subdomain или старого домена;
• staging и production используют разные OAuth apps или явно разделённые redirect URI;
• после изменения WEBHOOK_URL/base URL credential заново проверен.

Типичный симптом: провайдер пишет redirect_uri_mismatch, invalid_redirect_uri, unauthorized_client, а в n8n пользователь видит, что credential не может подключиться.

2. Разделить dev, staging и production ¶

Один OAuth app на все окружения кажется удобным, пока кто-то не меняет scopes или redirect URI ради теста. Для production лучше иметь отдельное приложение или хотя бы отдельные redirect URI, owners и credentials.

Если провайдер ограничивает количество apps, хотя бы документируйте, какие redirect URI и scopes относятся к какому контуру.

3. Scopes и consent screen ¶

Не ставьте максимальные scopes «чтобы точно заработало». Чем шире права, тем выше риск при утечке или ошибке workflow. Начинайте с минимальных действий: read, create, update. Delete, admin, billing, export и full mailbox доступ должны требовать отдельного обоснования.

Матрица проверки:

После изменения scopes часто нужен re-consent. Запланируйте окно и владельца, который может пройти авторизацию.

4. Владелец OAuth app и credential ¶

Production OAuth не должен зависеть от личного аккаунта одного сотрудника. Даже если сервис требует пользовательскую авторизацию, owner приложения и документированный recovery должны быть командными.

Проверьте:

• кто может зайти в консоль провайдера;
• кто может создать новый client secret;
• кто может добавить redirect URI;
• кто может пройти reauth;
• что произойдёт при увольнении владельца;
• есть ли второй администратор;
• где записана дата истечения client secret, если она есть.

5. Reverse proxy и публичный URL ¶

Self-hosted n8n часто стоит за Nginx, Caddy, Cloudflare, Traefik или load balancer. OAuth callback должен возвращаться на публичный URL, а не на внутренний hostname контейнера. Если n8n генерирует callback со старым доменом или localhost, проверьте base URL/proxy-настройки и deployment variables.

Быстрая проверка:

1. Открыть credential в n8n.
2. Скопировать OAuth Callback/Redirect URL.
3. Сравнить с настройкой у провайдера символ в символ.
4. Проверить, что URL доступен по HTTPS извне.
5. Пройти reauth в отдельном окне браузера.
6. Запустить read-only node с этим credential.

6. Token refresh и reauth ¶

OAuth credential может сломаться даже без изменения workflow. Причины: revoked consent, expired refresh token, смена пароля, политика организации, удалённый app, изменённые scopes, security review у провайдера.

Что добавить в production-процесс:

• дата последней успешной авторизации;
• owner для reauth;
• smoke test после reauth;
• мониторинг 401/403;
• понятное сообщение в alert: какой credential и какой workflow;
• runbook для замены client secret;
• список зависимых workflow.

7. Smoke tests перед запуском ¶

Проверка «credential saved successfully» недостаточна. Нужно выполнить действия, которые workflow реально делает.

Для критичных workflow добавьте тест после перезапуска контейнера n8n: иногда проблема скрывается в env или домене, а не в самом OAuth.

8. Частые ошибки и решения ¶

Контрольный чеклист ¶

• OAuth Callback/Redirect URL скопирован из n8n и совпадает у провайдера.
• Production использует HTTPS-домен, а не localhost или staging URL.
• Scopes минимальны и соответствуют действиям workflow.
• У OAuth app есть командный owner и второй администратор.
• Известно, кто делает reauth и где инструкция.
• Read/write smoke tests прошли на безопасных данных.
• 401/403 попадают в error workflow или alert.
• Список зависимых workflow сохранён перед изменением app.

FAQ ¶

Почему OAuth работал локально, но сломался на сервере?
Почти всегда из-за redirect URI или публичного URL. Локальный callback отличается от production callback, а провайдер требует точного совпадения.

Можно ли использовать один OAuth app для dev и production?
Технически часто можно, но лучше разделять. Иначе тестовые изменения scopes или redirect URI могут сломать production.

Нужно ли делать reauth после изменения scopes?
Часто да. Зависит от провайдера, но в production планируйте re-consent и smoke test.

Что делать, если credential принадлежит сотруднику?
Запланировать перенос на сервисный или командный аккаунт. До переноса назначить второго администратора и документировать recovery.

Как мониторить OAuth-проблемы?
Отслеживайте 401/403, invalid_grant, access_denied, падения конкретных nodes и рост failed executions для workflow, зависящих от OAuth.

{
  "event_id": "evt_...",
  "event_type": "object.updated",
  "received_at": "2026-05-29T10:00:00Z",
  "signature_valid": true,
  "dedupe_key": "provider:event_id",
  "payload_version": "v1"
}