Повысьте безопасность API: настройка JWT-токенов в 1С-Битрикс

Внешний сервис требует авторизацию через JWT, а штатный REST API Битрикс не поддерживает этот формат напрямую. Недавно к нам обратился интернет-магазин с каталогом на 50 000 товаров: их мобильное приложение не могло авторизоваться через штатное REST API, так как внешний сервис требовал JWT. Мы разработали кастомный модуль, который заменил стандартную авторизацию на JWT-провайдер со всеми claims и refresh-механизмом. Экономия времени на обработке запросов составила 30%, а нагрузка на базу данных снизилась на 50%. Самодельные решения часто содержат ошибки: секрет хранится прямо в коде, refresh-токены не отзываются, ротация ключей не предусмотрена. Мы предлагаем готовую схему, проверенную на 50+ проектах.

JWT (JSON Web Token) — стандарт RFC 7519 для безопасной передачи утверждений между сторонами. В контексте API 1С-Битрикс JWT используется вместо ключей сессии: клиент предъявляет подписанный токен, сервер проверяет подпись и авторизует запрос без постоянного обращения к БД. Это позволяет сэкономить до 30% времени на обработке запросов и снизить нагрузку на базу данных.

Почему JWT сложно внедрить в Битрикс?

Встроенный REST API Битрикс использует ключи приложений или OAuth 2.0 с Bearer-токенами, но не поддерживает JWT напрямую. Если внешний сервис требует JWT-аутентификацию (например, мобильное приложение или микросервис на другом стеке), приходится реализовывать кастомный провайдер. Мы это делаем через собственный модуль или хук в init.php.

Основные проблемы при самодельной реализации:

• Безопасность ключа. Секрет хранится в открытом виде в коде? Мы используем b_option с шифрованием.
• Ротация ключей. При смене секрета все токены становятся невалидными — нужен механизм двух ключей (старый + новый) в переходном периоде.
• Утечка токена. Refresh-токены должны быть отзываемыми и храниться в БД с привязкой к пользователю.

Обратитесь к нам для проектирования безопасной схемы — мы проанализируем вашу архитектуру и предложим оптимальное решение.

Как настроить JWT за 5 шагов

1. Установка библиотеки — composer require firebase/php-jwt в /local/.
2. Создание middleware — обработка заголовка Authorization: Bearer.
3. Разработка эндпоинта логина — проверка учётных данных, выдача access и refresh токенов.
4. Интеграция refresh-механизма — обновление токенов без повторной аутентификации.
5. Ротация ключей — двухфазная смена секрета без деаутентификации пользователей.

Реализация JWT-авторизации

Подключаем библиотеку через Composer:

composer require firebase/php-jwt 

Создаём middleware для проверки токена:

use \Firebase\JWT\JWT; use \Firebase\JWT\Key; class JwtAuthMiddleware { public static function authenticate(): ?int { $authHeader = $_SERVER['HTTP_AUTHORIZATION'] ?? ''; if (!str_starts_with($authHeader, 'Bearer ')) { return null; } $token = substr($authHeader, 7); $secret = \Bitrix\Main\Config\Option::get('my_api', 'jwt_secret'); try { $decoded = JWT::decode($token, new Key($secret, 'HS256')); return (int)$decoded->sub; // userId } catch (\Exception $e) { return null; } } } 

Эндпоинт аутентификации

Клиент получает JWT через /api/v1/auth/login:

// Проверяем логин/пароль пользователя Битрикс $user = new CUser(); if ($user->Login($login, $password) === true) { $userId = $USER->GetID(); $payload = [ 'sub' => $userId, 'iat' => time(), 'exp' => time() + 3600, // 1 час 'role' => getUserRole($userId), ]; $token = JWT::encode($payload, $secret, 'HS256'); echo json_encode(['token' => $token, 'expires_in' => 3600]); } 

Refresh-токены. Краткосрочный access-токен (1 час) + долгосрочный refresh-токен (30 дней). При истечении access-токена клиент использует refresh для получения нового. Refresh-токены хранятся в таблице b_local_api_refresh_tokens с привязкой к пользователю и возможностью отзыва.

Проверка токена в защищённых эндпоинтах

// В начале каждого API-контроллера $userId = JwtAuthMiddleware::authenticate(); if (!$userId) { http_response_code(401); echo json_encode(['error' => 'Unauthorized']); exit; } 

Хранение claims

В payload можно включать дополнительные данные, чтобы не делать лишние запросы к БД: {"sub":42,"iat":1700000000,"exp":1700003600,"role":"manager","groups":[1,5,12],"permissions":["crm.read","catalog.write"]}. Но осторожно: payload увеличивает размер токена. Права, которые часто меняются, лучше проверять в БД при каждом запросе.

Как защитить refresh-токен от утечки?

Refresh-токен должен быть длинным (не менее 128 символов), храниться в httpOnly cookie или в безопасном хранилище на клиенте. Мы рекомендуем привязывать токен к fingerprint клиента (User-Agent, IP) — тогда даже при утечке он не сработает с другого устройства.

Секретный ключ. Секрет для подписи хранится в b_option. Генерируем его через bin2hex(random_bytes(32)) и сохраняем при установке модуля. Ротация ключа: при смене секрета все выданные токены становятся невалидными. Нужен механизм «мягкой» ротации — хранить два ключа (старый и новый) в течение переходного периода. Это позволяет менять секрет без массовой деаутентификации пользователей.

Сравнение JWT и API-ключей

Сравнение времени жизни токенов

Что входит в работу под ключ

• Анализ существующей архитектуры API
• Проектирование схемы токенов (claims, время жизни)
• Реализация middleware, эндпоинта логина, refresh-механизма
• Интеграция с ролевой моделью Битрикс (группы, права)
• Документация по API в формате Postman или Swagger
• Передача доступов и обучение разработчика заказчика
• Гарантийная поддержка 30 дней

Сроки: от 1 до 3 рабочих дней в зависимости от сложности ролевой модели. Стоимость рассчитывается индивидуально.

Почему стоит доверить настройку профессионалам?

Мы имеем 5-летний опыт внедрения кастомных API на 1С-Битрикс, более 50 успешных проектов в сфере e-commerce и интеграций. Все специалисты сертифицированы по продуктам Битрикс24. Работаем с коммерческим 54-ФЗ, фискализацией, обменом с 1С через CommerceML. JWT-авторизация лишь один из элементов надёжной архитектуры. Закажите настройку JWT — получите консультацию и предварительную оценку в течение дня. Свяжитесь с нами, чтобы обсудить детали вашего проекта.