Вопрос или проблема
Контекст
Я читал где-то, что не следует использовать email (например, email, указанный в токене Google JWT) для совпадения при использовании SSO (например, OpenID Connect), но мне неясно, почему.
Рекомендуемый подход, по-видимому, заключается в использовании утверждений aud и sub или других аналогичных комбинаций, но у этого есть очевидные недостатки: например, если пользователь вошел через Google, а затем через несколько месяцев, не помня, какого провайдера SSO он использовал, входит через Facebook с тем же email, то будет создана новая учетная запись; если бы мы сопоставляли по адресу электронной почты, то две учетные записи были бы эффективно связаны.
Вопрос
Если доступ к электронной почте должен предоставлять доступ к приложению, в чем недостатки сопоставления пользователей по email, предоставленному провайдером SSO (при условии, что email_verified равно true)?
Ответ или решение
Сопоставление пользователей по электронной почте в системах единого входа (SSO) действительно вызывает определенные риски и недостатки. Рассмотрим ключевые моменты, которые необходимо учитывать при принятии решения о том, как идентифицировать пользователей.
1. Уникальность идентификаторов
Недостаток: Использование электронной почты в качестве основного идентификатора может привести к проблемам с уникальностью. Хотя почтовый адрес традиционно считается уникальным, пользователи могут менять свои адреса электронной почты или использовать несколько адресов. В результате может возникнуть ситуация, когда один и тот же пользователь будет иметь несколько учетных записей, если он использует разные SSO-провайдеры с различными адресами электронной почты.
2. Возможные конфликты и ошибки
Недостаток: Как вы упомянули в вашем вопросе, если пользователь зарегестрирован через одного поставщика SSO (например, Google) и затем решает войти с помощью другого (например, Facebook) с тем же адресом электронной почты, это может привести к созданию новой учетной записи. Основное правило работы с SSO заключается в том, что разные провайдеры могут иметь разные механизмы/данные по идентификации пользователей, и не всегда невозможно гарантировать, что почта одного провайдера соответствует почте другого.
3. Безопасность и конфиденциальность
Недостаток: Часто пользователи не понимают, что их почта может быть использована как идентификатор. Это открывает риски для безопасности и конфиденциальности. Например, если кто-то получит доступ к учетной записи пользователя на одном SSO-сервисе, он может попытаться использовать тот же адрес электронной почты для сброса пароля или доступа к другим учетным записям, что увеличивает риск атаки «по управлению учетной записью».
4. Анонимность пользователей
Недостаток: Использование электронной почты как идентификатора может утратить анонимность пользователей. Например, некоторые пользователи могут предпочитать соответствие без привязки своих реальных данных к учетной записи, и использование электронного адреса противоречит этому принципу.
5. Проблемы с переходом между сервисами
Недостаток: Если пользователь зарегистрировался во многих сервисах с различными способами аутентификации, и в какой-то момент он решает изменить свой провайдер SSO, могут возникнуть серьезные проблемы. Пользователю может оказаться трудно объединить свои учетные записи и вести учет своих данных.
Рекомендации
- Оптимальным вариантом является использование стандартных уникальных идентификаторов, таких как
sub(subject) из токена JWT, выданного SSO-поставщиком. Это обеспечивает уникальность и стабильность идентификатора. - Отображение аккаунтов может осуществляться, но только на основе записи, где каждый аккаунт привязан к конкретному SSO-поставщику, и необходимо предусмотреть дополнительный механизм для связывания этих аккаунтов.
- Применение элементов аутентификации на основе другого контекста, помимо электронной почты, может также помочь избежать вышеописанных проблем.
Итак, несмотря на привлекательность сопоставления по электронной почте, существуют весомые причины учитывать потенциальные проблемы и использовать более надежные методы идентификации пользователей.