Проверено: Drupal 10 +
openid_connect 3.0.0-alpha8 + openid_client_advanced 1.0.0-rc8;
канал Telegram. Работают вход, создание пользователя, проверка подписи id_token по JWKS,
nonce и PKCE S256.1. Модули
openid_connect 3.0.0 — alpha, и это стоит учитывать при планировании. openid_client_advanced
тянет firebase/php-jwt.
2. Клиент и три переключателя
Configuration → People → OpenID Connect, плагин advanced. Заполняютсяissuer_url, три
эндпоинта (/connect/authorize, /connect/token, /connect/userinfo) и scopes.
Включите все три: use_pkce, use_nonce, validate_signature с
allowed_algorithms: [RS256]. Ключи вставляются JSON-ом JWKS — поле ждёт содержимое
документа /.well-known/jwks, а не ссылку на него.
Ещё три настройки, без которых поведение будет неожиданным:
openid_connect.settings.user_login_display = above— иначе кнопки входа на форме просто не видно;override_registration_settingsиuser.settings.register— определяют, разрешено ли создавать учётные записи через провайдера.
redirect_uri = {адрес сайта}/openid-connect/{id сущности клиента}.
3. Drupal требует email — на каждом входе
Самое важное место рецепта.openid_connect отклоняет вход, если провайдер не вернул адрес:
в логе появляется No email address provided by <provider>, настройки обхода нет.
Telegram адреса не отдаёт и не отдаст. Выход — хук, который модуль документирует сам
(openid_connect.api.php) и вызывает до проверки; правка живёт в вашем модуле, contrib и
Veriqa остаются нетронутыми:
mymodule.module
telegram-123456789@telegram.veriqa.invalid. Домен .invalid
зарезервирован RFC 2606 и гарантированно никуда не
доставляется — это осознанная цена, а не бесплатный обход:
учётная запись с таким адресом не получит ни сброса пароля, ни уведомлений. Для боевого
сайта это развилка, а не готовое решение: спросить email вторым шагом, включить progressive
enrichment или использовать канал Email, где адрес приезжает в claims.
connect_existing_users — настройка, которую нельзя оставлять без внимания
Для нового пользователя Drupal сверяет адрес с существующими учётными записями. При включённом
connect_existing_users он привяжет найденную локальную учётку к идентичности из Veriqa.
С синтетическими адресами это безопасно: они детерминированы и уникальны на пару «канал + id».
Но как только Veriqa начнёт отдавать настоящий адрес (канал Email или собственный резолвер),
вход через Veriqa захватит локальный аккаунт с тем же адресом — классический захват учётной записи
через непроверенный email. Включать эту настройку осмысленно только тогда, когда вы уверены в
верифицированности адреса на стороне IdP.
Что получится
Учётная запись создаётся с именем изpreferred_username (alice), а в authmap появляется
запись provider=openid_connect.veriqa, authname=telegram:123456789 — Drupal связывает
идентичность по sub Veriqa.
Отсюда следует практическое: sub для Drupal — ключ учётной записи. Если способ его
формирования на стороне Veriqa изменится, ранее заведённые пользователи перестанут узнаваться.
Границы
- Проверено с каналом Telegram; связка Drupal с Email, WhatsApp и MAX не проверялась.
- Хук выше — пример, а не готовый модуль для продакшена: решение про адреса принимает сам сайт.