Два входа с одним email: когда аккаунты нельзя объединять

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

Два входа могут оказаться двумя разными записями

Пользователь зарегистрировался по почте, а позже нажал «Войти через провайдера». Приложение может увидеть новую внешнюю идентичность с тем же адресом. Кажется удобным сразу открыть прежний кабинет, но такое решение должно опираться на проверенную модель доверия. Нельзя принимать совпавшую строку за универсальное разрешение на доступ ко всем данным локальной записи.

Под словами «вход через OAuth» часто обсуждают целый пользовательский сценарий. Для идентификации в таких решениях может использоваться OpenID Connect; требования нужно проверять по реально выбранному протоколу и поставщику. Не переносите свойства OIDC-полей на произвольный ответ любого внешнего API. Разработчик должен объяснить, откуда пришли сведения и как подтверждена их подлинность.

В OpenID Connect Core sub определён как идентификатор пользователя в пределах issuer. Email не следует считать гарантированно уникальным идентификатором. email_verified сообщает о проверке контроля адреса в момент её выполнения у провайдера; это не утверждение о праве на любую локальную запись с той же почтой. Для OIDC-связи учитывают источник идентичности и её subject вместе.

Отделите привязку входа от слияния бизнес-данных

Добавить новый способ входа в тот же кабинет и объединить две базы заказов — разные операции. В одном случае меняется путь аутентификации, в другом — принадлежность рабочих данных. Мы советуем описывать их отдельными требованиями. Иначе разработчик может решить техническую проблему дубликата пользователя ценой незаметного объединения двух организаций.

Учебный пример: человек работает в двух компаниях и использует одинаковый контактный адрес в двух рабочих пространствах. Привязка внешнего входа не должна переносить счета, клиентов или права владельца из одного пространства в другое только из-за совпадения контакта. Приложение должно сохранить согласованную модель членства, даже когда пользователь хочет видеть один удобный экран входа.

Начинайте привязку как отдельное действие пользователя

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

В документации Auth0 по связыванию аккаунтов рекомендуется аутентифицировать обе учётные записи перед привязкой. Реализация зависит от выбранного сценария и возможностей Auth0. Это конкретная техническая рекомендация поставщика: она не означает, что включение похожей кнопки в любом приложении уже обеспечивает все проверки.

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

Что делать с уже существующим конфликтом

Если новый способ входа занят другой локальной записью, не переносите его молча. Нужен отдельный сценарий восстановления или разбор поддержки с подтверждением доступа. Сначала установите, какие записи существуют и какие рабочие данные за ними закреплены. В публичном сообщении не раскрывайте постороннему посетителю подробности чужого профиля, заказов и организаций.

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

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

Проверки для приёмки реализации

1. Зафиксируйте поддерживаемые способы входа и проверяемые идентификаторы. Для OIDC укажите пару issuer и subject, а также допустимые источники сведений.
2. Разделите операции: новый вход, привязка, отвязка и объединение бизнес-данных. Для каждой согласуйте подтверждение и ожидаемый результат.
3. На учебных аккаунтах проверьте штатную привязку с подтверждением обеих сторон. После завершения убедитесь, что открывается нужный кабинет с прежними согласованными правами.
4. Проверьте совпавший email без подтверждённой привязки, уже занятый способ входа, отмену и повторное открытие результата. Система не должна выдавать непредусмотренный доступ.
5. Проверьте отвязку и оставшийся способ входа. Пользователь не должен случайно потерять доступ к своему кабинету из-за непонятной последовательности действий.
6. Сохраните события изменения связей без секретных токенов и отправьте предусмотренное уведомление пользователю. У поддержки должен быть согласованный путь разбора ошибочной связи.

Как объяснить это заказчику и пользователю

Не требуйте от пользователя знать issuer и subject. В интерфейсе достаточно понятного имени провайдера, текущего аккаунта и результата действия. Технические идентификаторы нужны в закрытой диагностике разработчика. Сообщение об ошибке должно объяснять доступный следующий шаг, но не предлагать обойти подтверждение ради быстрого входа.

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

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