Skip to main content
TYPO3 подключается расширением causal/oidc — самым свежим OIDC-клиентом из проверенных движков. Сторона Veriqa не меняется.
Проверено: TYPO3 13.4.34 + causal/oidc 5.0.0; канал Telegram. Работают вход, создание fe_user и сессия, связывание идентичности по sub Veriqa.

​
1. Установка

Расширение требует TYPO3 12.4.33+/13.4.14+ и PHP 8.2+, тянет league/oauth2-client и firebase/php-jwt.

​
2. Настройка

Настройки живут не в базе, а в config/system/settings.php, ключ EXTENSIONS.oidc: redirect_uri у TYPO3 свободный — в отличие от Drupal и Joomla, где адрес навязан модулем. Middleware перехватывает любой фронтовый GET, в query которого есть code/state/error, поэтому зарегистрировать можно, например, корень сайта.
Страницу входа заведите отдельную. Плагин oidc_login редиректит на IdP сразу при рендере страницы — положить его на главную значит отправлять на вход каждого посетителя.

​
3. Группа по умолчанию — без неё вход не работает

Это главная засада TYPO3, и опасна она вдвойне. Нового пользователя расширение не создаёт, если он не попал ни в одну группу. Группы берутся либо из claim Roles — Veriqa такого не отдаёт, — либо из usersDefaultGroup. Значит запись fe_groups нужно завести руками и указать её uid. Вторая половина ловушки — диагностика. Отказ уходит в лог уровнем INFO, а дефолтный логгер TYPO3 держит порог на ERROR. Со стороны это выглядит так:
  • страница показывает голое «Login failed! Please try again.»;
  • в логе TYPO3 — ни строки о причине;
  • в логах Veriqa всё зелёное: token 200, userinfo 200.
Ошибка возникает уже после успешного обмена, поэтому интегратор ищет проблему у IdP, а она у него. Диагностический логгер стоит включать до первого входа, а не после.

​
4. Что расширение проверяет, а что нет

Подпись id_token расширение не проверяет — настройки JWKS у него нет вовсе: личность берётся из ответа /connect/userinfo, а доверие строится на TLS. Это законный выбор (OIDC Core §3.1.3.7), но подпись Veriqa на стороне TYPO3 не проверяется.
nonce расширение не отправляет и iss не сверяет — от replay его защищает только state и собственная кука контекста. Для строгого RP это слабее, чем Drupal. oidcEndpointUserInfo обязателен. Запасной путь «взять личность из id_token» содержит дефект расширения, дающий на PHP 8 фатальную ошибку вместо входа. Оставлять поле пустым нельзя.

​
Email и имя пользователя

TYPO3, как и WordPress, не требует email: дефолтный маппинг plugin.tx_oidc.mapping.fe_users его вообще не мапит. Вход через мессенджер создаёт рабочего fe_user без синтетических .invalid-адресов, которые нужны Drupal и Битриксу. Цена та же, что везде: по умолчанию username = <sub>, то есть telegram:123456789. Человекочитаемое имя даёт переопределение маппинга на <preferred_username>. Идентичность связывается по sub Veriqa — если способ его формирования на стороне Veriqa изменится, ранее заведённые пользователи перестанут узнаваться.

​
Границы

Проверено с каналом Telegram; TYPO3 с Email, WhatsApp и MAX не проверялся.