SSO в WordPress через OAuth и OpenID Connect: единый вход без лишних паролей

SSO в WordPress позволяет пользователю входить на сайт через уже существующую корпоративную или внешнюю учетную запись вместо отдельного пароля WordPress. Для компании это особенно удобно, когда сотрудники работают сразу с несколькими внутренними сервисами, личными кабинетами или закрытыми разделами.

Но в формулировке «подключить OAuth для входа» часто смешиваются два разных понятия. OAuth 2.0 — прежде всего framework авторизации доступа к ресурсам, а OpenID Connect добавляет поверх него стандартный слой идентификации пользователя. Для нормального browser SSO обычно нужен именно OpenID Connect или другой протокол аутентификации, а не произвольный access token.

OAuth 2.0 и OpenID Connect — не одно и то же

В спецификации OpenID Connect Core прямо указано, что OIDC является identity layer поверх OAuth 2.0. Он позволяет клиенту проверить личность пользователя после аутентификации у Authorization Server и получить стандартизированные claims.

Ключевой объект OIDC — ID Token. Он содержит данные о факте аутентификации и должен проверяться по правилам протокола. Access Token решает другую задачу: дает приложению доступ к защищенному API. Использовать случайный OAuth access token как доказательство личности без корректного OIDC-профиля — плохая архитектура.

Как выглядит SSO-схема для WordPress

1. Пользователь открывает защищенную страницу WordPress.
2. WordPress перенаправляет его к Identity Provider.
3. Пользователь проходит аутентификацию у провайдера.
4. Провайдер возвращает пользователя на заранее зарегистрированный callback URL.
5. WordPress обменивает authorization code на токены по защищенному каналу.
6. Интеграция проверяет ID Token: issuer, audience, подпись, сроки действия, nonce и другие необходимые поля.
7. Локальная учетная запись WordPress находится или создается по утвержденному правилу.
8. WordPress устанавливает обычную пользовательскую сессию.

После этого для WordPress пользователь уже авторизован локально, хотя пароль сайта он не вводил.

Почему Application Passwords WordPress не заменяют SSO

В WordPress есть Application Passwords, но они предназначены для API-клиентов и автоматизаций. В актуальной документации WordPress отдельно отмечено: такие пароли нельзя использовать для интерактивного входа через wp-login.php. Они подходят скриптам, REST API и внешним приложениям, а не людям, которые входят в браузере.

Поэтому интеграцию «корпоративный вход в wp-admin» нельзя корректно решить просто созданием Application Password для каждого сотрудника.

Discovery и конфигурация провайдера

OpenID Connect Discovery позволяет клиенту получить стандартные адреса endpoints и параметры провайдера: issuer, authorization endpoint, token endpoint, JWKS и другие метаданные. Это надежнее, чем жестко прописывать несколько URL из инструкции и забывать о них.

Интеграция должна проверять, что полученный issuer совпадает с ожидаемым, а ключи для проверки подписи берутся из доверенного metadata/JWKS источника.

Authorization Code Flow

Для серверного WordPress типичный вариант — Authorization Code Flow. Браузер получает короткоживущий authorization code, а обмен на токены происходит сервер-сервер. Это не означает, что «код безопасен сам по себе»: важны HTTPS, точный redirect URI, state, nonce, корректная проверка токенов и хранение client secret.

Нельзя принимать callback и просто читать email из непроверенного JWT. Сначала проверяется подпись и обязательные claims, только затем данные используются для сопоставления пользователя.

Как сопоставлять пользователя WordPress

Самая чувствительная часть SSO — linking. Email удобен человеку, но может измениться, повторно выдаваться или иметь разные правила в разных системах. В OIDC стабильная идентичность обычно определяется комбинацией issuer и subject (iss + sub).

Практический вариант — при первом успешном входе сохранить внешний issuer/subject в user meta, а дальше искать пользователя по этой паре. Email можно использовать для первоначального сопоставления только по заранее определенным правилам и, при необходимости, при наличии подтверждения, что он verified.

Автоматическое создание пользователей

Есть два основных режима. В первом WordPress разрешает вход только уже существующим пользователям. Во втором учетная запись создается при первом успешном SSO-входе.

Автопровижининг удобен для больших команд, но он требует жестких ограничений. Нельзя назначать роль администратора только потому, что провайдер вернул произвольный group claim или email с похожим доменом. Правила role mapping должны быть явными и иметь безопасное значение по умолчанию.

Роли и capabilities

WordPress проверяет доступ через роли и capabilities. SSO не должен обходить этот механизм. После успешной внешней аутентификации интеграция определяет локального пользователя, а его права внутри WordPress все равно должны контролироваться стандартными capabilities.

Если роли синхронизируются с группами IdP, нужно решить, что произойдет при удалении человека из группы, временной недоступности провайдера или появлении неизвестного значения. Безопаснее понижать привилегии предсказуемо, чем автоматически расширять их.

State, nonce и защита callback

state связывает исходящий authorization request с callback и помогает защищать flow от подмены контекста. В OIDC также используется nonce, который затем сверяется с ID Token. Оба значения должны генерироваться безопасно и иметь ограниченный срок жизни.

Callback endpoint не должен выполнять login только по факту наличия параметров code и state. Нужна полная серверная проверка ответа и корректная обработка ошибок провайдера.

Redirect URI должен быть точным

У провайдера заранее регистрируется разрешенный callback URL. Не стоит разрешать свободный redirect на адрес из query-параметра: это может превратить интеграцию в open redirect или увести токены/код не туда.

После успешного входа можно восстановить исходную страницу внутри сайта через заранее сохраненное и проверенное состояние, а не доверять произвольному внешнему URL.

Что делать, если Identity Provider недоступен

Если SSO становится единственным способом входа в административную часть, нужно предусмотреть break-glass сценарий. Например, отдельную локальную учетную запись администратора с сильной защитой, которая используется только при аварии.

Иначе ошибка конфигурации OIDC, истекший client secret или недоступность IdP может заблокировать доступ к WordPress одновременно всем администраторам.

Single Logout — отдельная задача

«Единый вход» не означает автоматически «единый выход». WordPress имеет собственную cookie-сессию, а Identity Provider — свою. Если пользователь нажал Logout только в WordPress, SSO-сессия у провайдера может остаться активной и при следующем входе пользователь вернется без пароля.

Нужна ли синхронизация logout и поддерживает ли ее конкретный IdP, определяется отдельно. Это лучше включить в требования проекта до разработки.

SSO для wp-admin, личного кабинета или обоих

Иногда SSO нужен только сотрудникам для wp-admin, а покупатели WooCommerce продолжают использовать обычный логин. В другом проекте единый вход нужен только фронтенд-кабинету. Эти сценарии не стоит смешивать.

Можно ограничить SSO конкретными ролями, доменами или страницами, сохранив обычный login там, где он действительно нужен.

Готовый плагин или кастомная интеграция

Готовый OIDC-плагин подходит, если провайдер стандартный, хватает базового mapping и нет сложной логики пользователей. Это обычно быстрее и дешевле.

Кастомная разработка плагина WordPress оправдана, если нужно связать SSO с внутренней системой, нестандартными claims, несколькими IdP, собственным onboarding, WooCommerce, CRM, аудитом или специальными правилами ролей.

Логи без утечки токенов

Для диагностики полезно логировать этап flow, идентификатор запроса, issuer, код ошибки, время и итог сопоставления пользователя. Но нельзя складывать access token, refresh token или client secret в обычный debug.log.

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

Что проверить перед запуском SSO

Настройка SSO WordPress в A.S Groups

A.S Groups выполняет разработку WordPress и интеграции с внешними API. Можно подключить существующий OIDC-провайдер, настроить готовый плагин или сделать отдельный модуль с user mapping, ролями, аудитом и безопасным fallback.

Для первичной оценки нужны адрес WordPress-сайта, название Identity Provider, документация OIDC/OAuth, список пользователей или ролей и сценарий: кому именно нужен единый вход. Связаться можно через форму A.S Groups.

Частые вопросы

Официальные источники

• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0
• WordPress — Application Passwords