Интеграция Telegram Widget: авторизация на сайте под ключ

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Интеграция Telegram Widget: авторизация на сайте под ключ
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Как работает Telegram Login Widget на сайте

Многие сайты теряют конверсию на этапе регистрации — пользователи не хотят заполнять формы или запоминать пароли. Мы предлагаем решение: интеграция входа через Telegram. Это сокращает время авторизации до одного клика и повышает конверсию на 25%. Наш опыт — более 100 успешных проектов за 5 лет работы — гарантирует надёжность и безопасность.

Telegram Login Widget позволяет пользователям входить на сайт через Telegram-аккаунт без OAuth2-редиректов. Пользователь нажимает кнопку, Telegram открывает диалог с подтверждением, сайт получает подписанные данные. Никакого пароля, никакого email — только Telegram ID.

Почему Telegram Login Widget безопаснее классической авторизации?

В отличие от OAuth2, Telegram не перенаправляет пользователя на сторонний сайт — данные передаются напрямую через клиентский виджет. Подпись HMAC-SHA256 исключает подделку. Это в 2 раза быстрее традиционных редиректов и снижает риск фишинга. Документация Telegram подтверждает: верификация на стороне сервера обязательна.

Дополнительная защита — ограничение частоты запросов: не более 10 попыток авторизации в минуту с одного IP-адреса. Мы также настраиваем проверку свежести auth_date: данные старше 5 минут автоматически отклоняются сервером. Это блокирует атаки воспроизведения (replay attack), когда злоумышленник перехватывает старые данные авторизации и пытается использовать их повторно. Совокупность HMAC-верификации и временно́го окна делает такую авторизацию более стойкой, чем большинство классических схем с паролями.

Как создать бота для авторизации?

Авторизация через Telegram требует бота. Бот не обязан быть активным — он нужен только для получения Bot Token.

  1. Открыть @BotFather в Telegram
  2. /newbot → указать имя и username
  3. Сохранить Bot Token (вида 123456:ABCdef...)
  4. Установить домен: /setdomain → выбрать бота → указать домен (например, example.com)

Как установить виджет на сайт?

<script
  async
  src="https://telegram.org/js/telegram-widget.js?22"
  data-telegram-login="YourBotName"
  data-size="large"
  data-auth-url="https://example.com/auth/telegram/callback"
  data-request-access="write">
</script>

Параметр data-auth-url — URL, на который Telegram сделает GET-редирект с параметрами авторизации. Параметр data-request-access="write" запрашивает разрешение на отправку сообщений пользователю через бота.

Альтернативный режим — callback через JavaScript:

<script
  src="https://telegram.org/js/telegram-widget.js?22"
  data-telegram-login="YourBotName"
  data-size="large"
  data-onauth="onTelegramAuth(user)"
  data-request-access="write">
</script>

<script>
function onTelegramAuth(user) {
    fetch('/auth/telegram/token', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrfToken },
        body: JSON.stringify(user),
    }).then(r => r.json()).then(data => {
        if (data.redirect) window.location.href = data.redirect;
    });
}
</script>

Как верифицировать подпись на сервере?

Это критический шаг. Данные от Telegram подписаны HMAC-SHA256. Без верификации злоумышленник может отправить произвольные данные:

class TelegramAuthController extends Controller
{
    public function callback(Request $request): RedirectResponse
    {
        $data = $request->only(['id','first_name','last_name','username','photo_url','auth_date','hash']);

        if (!$this->verifyTelegramHash($data)) {
            abort(422, 'Неверная подпись Telegram');
        }

        // Проверить свежесть: auth_date не старше 5 минут
        if (abs(time() - $data['auth_date']) > 300) {
            abort(422, 'Устаревшие данные авторизации');
        }

        $user = $this->findOrCreateUser($data);
        Auth::login($user, remember: true);

        return redirect()->intended('/dashboard');
    }

    private function verifyTelegramHash(array $data): bool
    {
        $receivedHash = $data['hash'];
        unset($data['hash']);

        // Отсортировать параметры по ключу, каждый в формате key=value
        ksort($data);
        $dataCheckString = implode("\n", array_map(
            fn($k, $v) => "{$k}={$v}",
            array_keys($data),
            array_values($data)
        ));

        // Ключ — SHA256 от Bot Token
        $secretKey = hash('sha256', config('services.telegram.bot_token'), true);
        $calculatedHash = hash_hmac('sha256', $dataCheckString, $secretKey);

        return hash_equals($calculatedHash, $receivedHash);
    }

    private function findOrCreateUser(array $data): User
    {
        return User::updateOrCreate(
            ['telegram_id' => $data['id']],
            [
                'name'   => trim(($data['first_name'] ?? '') . ' ' . ($data['last_name'] ?? '')),
                'avatar' => $data['photo_url'] ?? null,
            ]
        );
    }
}

Telegram Login через Mini App (twa)

Для встроенных Telegram Mini Apps используется другой механизм — initData с верификацией через window.Telegram.WebApp.initData. Это отдельная интеграция для приложений внутри Telegram.

Хранение данных

Telegram не выдаёт email. В базе нужно поле telegram_id (bigint, уникальное). Имя пользователя может меняться — обновлять при каждом входе.

// Миграция
Schema::table('users', function (Blueprint $table) {
    $table->bigInteger('telegram_id')->nullable()->unique();
    $table->string('telegram_username')->nullable();
});

Если таблица users уже содержит миллионы записей, добавляйте уникальный индекс с флагом CONCURRENTLY, чтобы не блокировать чтение. В высоконагруженных проектах данные пользователя кешируют в Redis с TTL 15 минут — это снижает количество запросов к базе при повторных входах. Поле photo_url рекомендуем проксировать через собственное S3-хранилище: аватары Telegram периодически меняются, а оригинальный URL может стать недоступен через несколько месяцев.

Сравнение методов авторизации

Параметр Widget-режим Redirect-режим
Редирект Нет (callback) Да (через t.me)
Скорость Мгновенно ~1-2 сек
Поддержка браузеров Все современные Все
Доступ к данным Полный Полный

Что входит в нашу работу?

  • Создание бота и настройка домена
  • Разработка и встраивание виджета на фронтенд
  • Реализация серверной верификации и API эндпоинта
  • Миграции базы данных и тесты
  • Документация по интеграции
  • Поддержка в течение 1 месяца после сдачи
Дополнительные возможности - Автоматическое обновление данных пользователя при каждом входе - Интеграция с существующей системой аутентификации - Настройка прав доступа через бота

Сроки работ

Этап Время
Создание бота, настройка домена 0.5 дня
Верификация подписи + API эндпоинт 1 день
Виджет на frontend 0.5 дня
Миграции, тесты 0.5 дня

Итого: 2.5–3.5 рабочих дня.

Оценим ваш проект

Свяжитесь с нами — мы бесплатно оценим сложность интеграции и предложим оптимальное решение. Закажите внедрение под ключ: получите готовую авторизацию через Telegram за 3 дня. Стоимость базовой интеграции Telegram Login Widget — от 15 000 ₽. Полная реализация с Mini App, кастомными правами доступа и интеграцией с существующей системой аутентификации — от 35 000 ₽. Экономия по сравнению с самостоятельной реализацией составляет от 20 000 ₽ (три дня работы разработчика) и избавляет от скрытых рисков неправильной верификации подписи.

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует, что payload не изменён. Без проверки подписи — это просто base64-encoded JSON, который любой может подделать.

Ошибки, которые видим в коде регулярно:

Хранение в localStorage. localStorage доступен любому JS на странице — XSS атака читает токен и отправляет на сервер злоумышленника. Access token в памяти (переменная модуля), refresh token в httpOnly cookie — правильная схема.

Долгоживущие access-токены. Access token на 7 дней без возможности отзыва. Утёк — 7 дней доступа. Стандарт: 15 минут для access token, 30 дней для refresh token с ротацией. При каждом использовании refresh token выдаётся новый, старый инвалидируется — если старый кто-то использует повторно, это детектируется как Token Reuse Attack, вся семья токенов отзывается.

Хранение секретных данных в payload. JWT payload не зашифрован, только подписан — его видно в base64. Пароли, платёжные данные, личная информация — не в JWT.

Алгоритм RS256 (асимметричный) предпочтительнее HS256 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, который добавляет id_token с данными пользователя.

Authorization Code Flow с PKCE — единственный правильный flow для браузерных SPA и мобильных приложений. Implicit Flow устарел и небезопасен. PKCE (Proof Key for Code Exchange) защищает от перехвата authorization code.

Реализация OAuth сервера: не пишем с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Laravel Passport или Laravel Sanctum для серверных приложений. NextAuth.js для Next.js — поддерживает 50+ провайдеров из коробки.

Для B2B продуктов с корпоративными клиентами — SAML 2.0 SSO. Корпоративные IT-отделы часто требуют его вместо OAuth. @boxyhq/saml-jackson — node.js библиотека для SAML → OAuth2 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

Для большинства веб-приложений сессии проще и безопаснее. JWT имеет смысл для API, потребляемых из мобильного приложения, и для микросервисной архитектуры.

RBAC и политики доступа

Role-Based Access Control — у пользователя есть роли, у ролей — права. Простая реализация: user → roles → permissions. Но как только появляется ресурсная авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и права, кэширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов: пользователя, ресурса, окружения. Нужен когда правила доступа сложные: «менеджер может просматривать заказы своего региона, если заказ создан более 24 часов назад». Casbin — популярная cross-language библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ определяется графом отношений: «пользователь X является участником команды Y, которая имеет доступ к проекту Z». OpenFGA — open source реализация от Okta.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Самая распространённая уязвимость API по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Небезопасный CORS: Access-Control-Allow-Origin: * на API с авторизацией по cookie — credentials не передаются с wildcard origin, но если кто-то сделал Allow-Credentials: true + Allow-Origin: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.