Проверено: WordPress 6 +
openid-connect-generic 3.11.3; канал Telegram. Работают вход,
автоматическое создание пользователя, проверка подписи id_token по JWKS. Связка
WordPress + Email/WhatsApp/MAX не проверялась.Что понадобится
- развёрнутый сервер Veriqa с адресом, доступным сайту (в проде — публичный HTTPS с валидным сертификатом);
- зарегистрированный в Veriqa клиент:
client_id,client_secretиredirect_uriвидаhttps://ваш-сайт/wp-admin/admin-ajax.php?action=openid-connect-authorize; - права администратора в WordPress.
1. Плагин
Ставитсяopenid-connect-generic (10k+ установок, поддерживается). Альтернативы не подходят:
nicko170/wp-openid не обновлялся с 2023 года, плагин Scouting прибит к чужому issuer,
miniOrange прячет нужные настройки в платной редакции.
2. Настройки плагина
Адреса берутся из discovery вашего сервера (https://veriqa.example.com/.well-known/openid-configuration):
Четыре настройки стоит назвать отдельно — они определяют, как будет выглядеть учётная запись:
identity_key— не трогайте. На дефолте логин получается человекочитаемым (alice); выставленный вручнуюsubдаёт логин видаtelegram123456789.nickname_key→preferred_username,displayname_format→name.enable_logging— включите хотя бы на время настройки: лог плагина сокращает разбор проблем с часов до минут.no_sslverify— оставьте выключенным. Проверка TLS должна работать; если она мешает, проблема в сертификате, а не в проверке.
3. Уберите scope из запроса обмена кода
Это обязательный шаг, и его стоит понять, а не просто выполнить.
Плагин кладёт scope в запрос grant_type=authorization_code, где
RFC 6749 §4.1.3 его не предусматривает:
набор scope приходит из самого кода авторизации. Keycloak, Auth0 и Azure лишний параметр молча
игнорируют — строгий сервер на OpenIddict отвергает запрос (issue #1729 в OpenIddict закрыт как
invalid).
Снятие параметра делает запрос соответствующим стандарту. Это не обход проверки и не
ослабление вашей безопасности: убирается то, чего в запросе быть не должно.
Правит владелец сайта
mu-plugin в шесть строк на стороне WordPress. Сервер Veriqa не трогается — подходит, когда
Veriqa вам не принадлежит (например, это облако или чужое развёртывание).
Правит владелец Veriqa
Квирк совместимости
drop-scope-on-code-exchange — послабление для одного ClientId на
стороне сервера. Подходит, когда сайтов много, а лезть в каждый не хочется.Вариант А — mu-plugin
Положите файл вwp-content/mu-plugins/ (создайте каталог, если его нет). Must-use плагины
включаются автоматически — активировать в админке ничего не нужно.
wp-content/mu-plugins/veriqa-oidc-compat.php
scope снимается только у операции get-authentication-token. У обновления
токена он остаётся — там RFC 6749 §6 сужение scope разрешает.
Вариант Б — квирк на стороне Veriqa
Тот же параметр снимается сервером, для одного клиента. Включение двухступенчатое, и Veriqa пишет о включённом квирке предупреждение в лог при старте:appsettings.json
wordpress-openid-connect-generic —
в Совместимости с клиентами.
Без любого из двух вариантов вход падает на обмене кода, и WordPress возвращает браузер на
wp-login.php?login-error=invalid_request&message=….
Что получится
В логе плагина —login-success Successful login for: telegram123456789; от клика до входа
проходит порядка двадцати секунд, включая время, которое человек тратит на телефон. Пользователь
создаётся автоматически.
Учётная запись создаётся с пустым email — Telegram адреса не отдаёт и не отдаст. Если email
для вашего сайта обязателен, есть два пути: канал Email (тогда адрес приезжает в claims) или
запрос адреса самим WordPress после первого входа.
Границы
- Проверено с каналом Telegram. На канале Email профиль выглядит иначе:
nameдублирует адрес, а не человекочитаемое имя, поэтому рецепт, отлаженный на Telegram, даст другой вид учётной записи. - Отдельный плагин «Veriqa for WordPress» не нужен: штатный плагин закрывает задачу целиком.
- Аватар в этот рецепт не входит:
picture— изображение в виде URIdata:, выдаётся только по scopeavatarи только через userinfo, а настройка плагина выше этот scope не запрашивает.