Вход через Сбер ID, VK ID и Яндекс ID на сайте компании: как подключить и какие ошибки в реализации проверить

Интеграция сторонних сервисов идентификации давно стала привычным инструментом для ускорения регистрации и входа на сайты. Человеку не надо придумывать пароль, а компания сразу получает проверенную почту или телефон. Конверсия обычно растёт, поэтому кнопки входа через сервисы ставят многие.

Но с кнопками приходят и неочевидные архитектурные задачи. Михаил Ванин, генеральный директор Identity Blitz, рассказывает, как устроено подключение таких сервисов и какие ошибки могут возникнуть при их внедрении.

Два способа подключения

Под капотом у ID-сервисов лежит OpenID Connect. У каждого сервиса свои особенности, но схема одна: сайт отправляет человека к поставщику идентификации (Identity Provider), тот проверяет, кто этот пользователь, и возвращает набор данных о нём.

Выбор способа интеграции зависит от масштаба проекта и количества подключаемых провайдеров:

• Готовые виджеты. Провайдер ID-сервиса даёт JavaScript-код, который вставляется на страницу входа. Если нужен один сервис, скажем, только Яндекс ID, это самый быстрый путь: виджет уже отлажен, и пользователи узнают привычную кнопку. Хуже становится, когда провайдеров два-три. У каждого свой стиль, свои события, свои способы обработки ошибок. Страница входа превращается в набор разнородных библиотек, и сделать из них единый аккуратный интерфейс может быть непросто.
• Отдельная IAM-система. Если компания собирается подключать несколько внешних сервисов (Альфа ID, VK ID, ВТБ ID, Госуслуги, Mail ID, Мос ID, МТС ID, Одноклассники, Сбер ID, Т-ID, Яндекс ID) и ещё сохранить обычный вход по паролю, целесообразнее поставить коммерческую IAM-платформу. Она берёт на себя протокольную интеграцию со всеми внешними провайдерами. Интерфейс настраивается централизованно, там же собирается аудит, а ненужного провайдера всегда можно выключить, не трогая код сайта.

Пять частых ошибок

Протокол можно подключить идеально и всё равно получить дыры в безопасности и раздражённых пользователей. Дело обычно не в OIDC, а в сценариях вокруг него.

1. Автоматическое объединение по электронной почте

Человек зарегистрировался на сайте с адресом user@example.ru. Через месяц нажал «Войти через Яндекс ID», Яндекс вернул тот же адрес, и система «склеила» два профиля.

Выглядит удобно, пока внешний аккаунт не взломали. В этом случае злоумышленник получает доступ к внутреннему аккаунту пользователя без единого пароля. Для финансового сервиса или портала с персональными данными это серьёзная брешь в безопасности.

Правильнее при первом входе через новый сервис спросить подтверждение: пароль от существующей учётной записи или код из СМС либо письма. Связка создаётся только после того, как человек доказал, что владеет и тем, и другим аккаунтом.

Логика получается такая: пользователь нажал «Войти через Яндекс ID». Если связка с этим аккаунтом уже есть, пускаем в кабинет. Если нет, смотрим, есть ли в базе такой email или телефон. Нашли — просим пароль или код и только потом связываем. Не нашли — предлагаем создать новый профиль и ждём согласия.

Для приложений с высокими требованиями к безопасности не стоит ограничиваться только входом через внешний сервис идентификации, так как его могут взломать и после первичной привязки. Лучше запрашивать ещё что-то для подтверждения входа, особенно если в стороннем сервисе нет принудительного второго фактора.

2. Привязка только из личного кабинета

Бывает, что ID-сервис можно привязать лишь в настройках уже созданного профиля. А человек пришёл на страницу входа, нажал кнопку и увидел ошибку «Аккаунт не привязан».

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

Лучше связывать аккаунты «на лету». Если внешний аккаунт незнаком, интерфейс сам предлагает два варианта: привязать к существующей учётной записи или быстро зарегистрироваться.

3. Один внешний аккаунт — много внутренних

Человек может привязать один и тот же внешний аккаунт к разным профилям на сайте: например, если он забыл пароль и зарегистрировался заново. Если база данных рассчитана на связь «один к одному», попытка привязать один Яндекс ID к двум профилям закончится либо ошибкой, либо тихой перезаписью старой связки. Второе хуже: пользователь потом не поймёт, почему он стал входить в другой аккаунт, а не в тот, который был раньше.

Решение принимается ещё при проектировании модели данных. Можно запретить такие привязки и честно сказать: «Этот профиль Яндекс ID уже связан с другой учётной записью». Можно разрешить и после входа показывать выбор: в какой из ваших профилей заходим сейчас.

4. Один провайдер как единственный путь

Полагаться только на сторонние ID-сервисы рискованно: даже у крупных поставщиков бывают сбои, а иногда меняются правила (например, сервис стал платным или решил отключить возможность входа). Оставьте запасной вход: логин с паролем и вторым фактором либо одноразовые коды.

5. Стена из логотипов

Желание угодить всем пользователям приводит к форме, где красуется десяток кнопок: Альфа ID, VK ID, ВТБ ID, Госуслуги, Mail ID, Мос ID, МТС ID, Сбер ID, Т-ID, Яндекс ID. Дизайнеры называют это «эффектом Nascar», по сходству с машиной, обклеенной спонсорами. Человек теряется, дольше выбирает и чаще уходит. А каждую кнопку надо разрабатывать и годами поддерживать.

Выберите двух-трёх внешних провайдеров, которыми действительно пользуется ваша аудитория. Добавьте беспарольные способы, которым не нужен посредник: вход по отпечатку пальца или лицу (Passkey/WebAuthn) или вход по QR-коду. Они удобны, а страница остаётся чистой.

Что нужно администратору

Безопасность не заканчивается на экране входа. Администраторы системы должны иметь полноценные инструменты управления внешними идентификаторами:

• Журнал с указанием способа входа. Администратор должен видеть разницу между «вошёл по паролю» и «вошёл через Яндекс ID». Без этого расследовать инцидент или заметить аномалию сложно.
• Ручное управление связками. Если человек потерял доступ к соцсети, поддержка должна уметь отвязывать внешний аккаунт или блокировать его использование. Также нужна возможность объединить случайно задвоенные профили.
• Статистика входов. Некоторые сервисы берут деньги за авторизацию или за передачу дополнительных данных. По цифрам видно, чем пользуются на самом деле, какого провайдера можно отключить, и можно сверить счета.

Используемые термины

OpenID Connect, OIDC — протокол аутентификации, который позволяет приложениям безопасно узнавать личность пользователя с помощью сторонних сервисов.

Identity Provider — это централизованный ИТ-сервис, который создает, хранит и управляет цифровыми учетными записями пользователей, а также отвечает за их аутентификацию.

ID-сервис — инструмент, позволяющий пользователю быстро и безопасно входить на разные сайты, в приложения и сервисы без создания отдельного пароля для каждого из них.

JavaScript — высокоуровневый мультипарадигменный язык программирования, отвечает за интерактивность сайтов и веб-приложений.

IAM — управление идентификацией и контролем доступа.

Passkey — метод аутентификации без пароля, который позволяет входить в приложения и на сайты с помощью отпечатка пальца, сканирования лица (Face ID) или PIN-кода.

WebAuthn — веб-стандарт W3C для безопасной беспарольной аутентификации пользователей с помощью криптографии с открытым ключом.