Когда я строила свой сайт на Node.js, передо мной встал вопрос: как защитить внутренние API? Заказ из формы, данные из базы — всё ходит по внутренним вызовам. Сначала думала — поставлю OAuth и будет красиво. Потом разобралась и поняла: для малого бизнеса это overkill, который убивает и скорость, и бюджет.

Давайте разберём три подхода честно, с плюсами и минусами. Без рекламы «enterprise-ready» решений.

API Keys — простота, которая работает

Самый древний и понятный способ. Генерируешь ключ, даёшь клиенту, клиент шлёт его в заголовке. Всё.

Плюсы:

  • Элементарно внедрить — 10 строк кода
  • Работает быстро — один заголовок, никаких вычислений
  • Легко отзывать — удалил ключ из базы и всё
  • Дешево для внешних интеграций: платёжные агрегаторы, CRM, рассыльщики

Минусы:

  • Ключ — это пароль. Если утек в логах или код — злоумышленник получил доступ ко всему
  • Нет гранулярности — один ключ на все операции
  • Клиент не может ограничить доступ ключа сам

JWT — токены, которые всё знают

JSON Web Token. Сервер подписывает пакет данных криптографически и отдаёт клиенту. Клиент шлёт токен с каждым запросом, сервер проверяет подпись.

Плюсы:

  • Не нужно хранить сессии на сервере — stateless
  • Можно передавать данные внутри токена (роль, email, права)
  • Масштабируется горизонтально — любой сервер проверит токен
  • Время жизни встроено — токен умрёт сам

Минусы:

  • Размер. JWT с кучей данных увеличивает каждый запрос. На мобильном или плохом интернете — заметно
  • Если токен скомпрометирован — отзывать сложнее. Либо blacklist, либо ждать истечения
  • Можно случайно положить в логи или URL — и он утечёт
  • Приватный ключ для подписи — это новая точка отказа

OAuth 2.0 — когда это действительно нужно

Полноценный протокол авторизации. Клиент получает доступ не от имени пользователя, а с его согласия. Google-вход, доступ к календарю, интеграция с CRM — типичные сценарии.

Плюсы:

  • Пользователь даёт минимальный доступ (scopes)
  • Можно отозвать доступ без смены пароля
  • Standard — все понимают как работает

Минусы:

  • Сложность. Даже простой OAuth-вход требует библиотеки, обработки redirect, ротации токенов
  • Дорого для маленького проекта — разработка и поддержка
  • Scope-правила нужно продумывать заранее
  • Для большинства малых сайтов это просто не нужно

Что выбрать для типичного сайта

Магазин запчастей, салон красоты, мастерская по ремонту — не банк и не enterprise. Им нужен простой сайт, который показывает товары, принимает заказы, интегрируется с CRM.

Мой вывод для малого бизнеса:

  • Внутренние API (браузер ↔ сервер) — JWT. Быстро, stateless, сервер легко масштабировать
  • Внешние интеграции (платёжные системы, CRM) — API Keys. Просто и понятно, один ключ на сервис
  • Пользовательский вход — если нужен свой аккаунт, то JWT + httpOnly cookie. Если вход через Google или ВКонтакте — OAuth, но только для этого
  • OAuth 2.0 целиком — только если у вас маркетплейс или сложная партнёрская программа

Главное — не инструмент, а паттерн

Какой бы способ вы ни выбрали, есть три вещи, которые убивают API в любом случае:

  • Нет rate limiting — боты смогут перебирать ваши данные или забивать запросами
  • Ключи и токены в коде или публичных репозиториях — это 90% утечек. Ключи в .env файле, не в git
  • Слишком много данных в одном токене — JWT раздувается, скорость падает

Проверить своё API на базовые уязвимости можно через Google Lines или OWASP ZAP — оба бесплатные и покажут основные проблемы без дорогих пентестов.

Не гонитесь за OAuth, если у вас обычный сайт. Простое и надёжное всегда побеждает сложное и хрупкое.