Skip to main content
Второй сценарий, помимо входа: пользователь заполняет форму — заявку, вопрос, запрос обратного звонка — и подтверждает отправку в мессенджере. Рядом с заявкой у вас появляется запись «эту отправку подтвердил такой-то субъект в таком-то канале», а сессия не создаётся и учётная запись не заводится.
Обработчик укладывается примерно в 250 строк PHP, без Composer и без внешних зависимостей; проверено на канале Telegram.

​
Почему это не настройка входа

Ни один OIDC-плагин CMS этого не умеет. Плагины закрывают вход в аккаунт, а Contact Form 7, WPForms и веб-формы Битрикса к аккаунту не привязаны вовсе. «Личный кабинет» и «подтверждённая заявка» — два разных решения, а не две настройки одного.
Поэтому здесь не нужен ни плагин, ни готовый рецепт CMS: нужен небольшой серверный обработчик, который вы кладёте рядом с формой.

​
Почему обязателен серверный обработчик

Сделать это одним браузерным скриптом нельзя, и упирается это в три вещи сразу:
  • поддерживается только Authorization Code Flow (плюс refresh) — implicit и hybrid отсутствуют;
  • CORS не настроен ни на одном эндпоинте;
  • access token — непрозрачный идентификатор, а интроспекция требует confidential-клиента с секретом, которого браузерный скрипт хранить не может.
Практическое следствие для SaaS-конструкторов (Tilda, Wix, Shopify): сценарий требует хостинга под этот обработчик — самой страницы конструктора недостаточно.

​
Схема

  1. пользователь жмёт кнопку под формой;
  2. переход на /connect/authorize с PKCE S256, state и nonce — плюс acr_values, если нужен конкретный канал;
  3. возврат на redirect_uri — обычную страницу вашего сайта;
  4. сервер меняет код на токены и проверяет iss, aud, exp и nonce;
  5. рядом с заявкой записывается «подтверждено: sub + channel_type»;
  6. кука аутентификации не ставится — входа не происходит.

​
Про проверку подписи

Проверять подпись id_token JWT-библиотекой здесь не обязательно: OIDC Core §3.1.3.7, правило 6 разрешает клиенту, получившему токен прямым обращением к токен-эндпоинту, полагаться на проверку TLS вместо проверки подписи. Именно поэтому обработчику не нужны ни JWT-библиотека, ни Composer.
У послабления есть цена, и она не обсуждается: проверку TLS-сертификата отключать нельзя ни при каких условиях (CURLOPT_SSL_VERIFYPEER в PHP — всегда включён). Без неё исчезает ровно то, на чём держится разрешение не проверять подпись.

​
Свои кнопки на своей странице

Две кнопки под формой — «Через Telegram» и «любым способом» — делаются параметром authorize-запроса: acr_values=channel:telegram сужает выбор до одного канала, без параметра пользователь выбирает сам.
Виджета или JS-SDK для этого не существует и не требуется: «своя кнопка» — это ссылка с нужными параметрами, а не встраиваемый компонент.