Проверенное двунаправленное подключение аккаунта через платформу идентичности из девяти брендов

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

Ограничения были конкретными. Связывание должно было быть двунаправленным и независимым от порядка: сначала Google, затем Apple, или сначала Apple, потом Google, должны были достичь одного и того же общего аккаунта. Скрыть мою почту от Apple пришлось обрабатывать отдельно, потому что приватный адрес, не совпадающий с настоящим аккаунтом клиента, не должен тихо подключаться к этому аккаунту. Верификация должна была повторно использовать тот же механизм вызова кода, который уже доверялся для аутентификации с повышенным риском, поэтому связывать унаследованные проверенные контроли вместо изобретения новых. Риск должен был модулировать трение: входы с низким риском должны оставаться без трения, тогда как средний, высокий и неопределённый риск требовал OTP. Повторяющиеся сбои нужно было сдерживать с помощью политики блокировки, которая действовала на уровне аккаунта, для каждого бренда, а не для каждого бренда. А сбои провайдера должны были быть безопасными, никогда не оставляя клиента с частичным или дубликатом аккаунта.

Один и тот же проверенный путь охватывал оба направления связывания. Если клиент создал аккаунт в Google и позже выбрал «Продолжить с Apple» с тем же общим email, система обнаружила существующий аккаунт, отправляла код на почту и связывала Apple после успешной верификации. Наоборот, сначала Share My Email от Apple, а потом Google — разрешились на тот же общий аккаунт через тот же вызов. После привязки клиент мог войти в Apple, Google или использовать электронную почту и пароль в любом случае настройки, и попасть на тот же аккаунт.

Программа Apple Hide My Email осталась сознательно отдельным путём. Если адрес приватного ретрансляции не совпадает с нераскрытым личным email клиента, личности не подпадали под ссылку на одну и ту же почту. Вместо того чтобы связать реле с несвязанным аккаунтом, платформа показала объяснение с ограниченным доступом и создала отдельный аккаунт для электронной почты. Помимо первого подключения, один и тот же аккаунт имел свой жизненный цикл: клиент мог установить пароль на социальной учетной записи, изменить основную электронную почту (что отключило предыдущий социальный провайдер и требовало повторной проверки), и каждый возвращающийся вход проходил через оценку рисков перед началом сессии.

Оттуда поток разветвился на чётко ограниченные исходы. Подходящий по электронной почте выдавался код связи с существующей электронной почтой аккаунта; После успешной проверки провайдер был связан с поставщиком, а в случае неудачи попытка отклонялась и записывалась в ответ. Электронное письмо Apple, которое не совпадало, направлялось к объяснению с ограниченным доступом и отдельной учетной записи relay-email. После разрешения на общий кросс-брендовый аккаунт проверялся статус: заблокированный аккаунт отображался как заблокированный, активный — в категорию риска. Low risk выпустила аутентифицированную сессию напрямую; средний, высокий и неопределённый риск отправлял OTP на аутентификацию, а повторные неудачные вызовы до фиксированного порога блокировали общий аккаунт всех девяти брендов. Сам аккаунт раскрывал настройки пароля и изменения электронной почты, при этом изменение основного письма отключило предыдущего социального провайдера и требовало повторной проверки провайдера. Сбои сервиса провайдера не создавали частичного состояния: они возвращали безопасную ошибку и повторную попытку, которая возвращалась к тому же оркестратору, поэтому неудачный звонок Apple или Google не привёл к полусвязному или дублирующему аккаунту. Граница связки объединяла три проверки: проверенный ответ провайдера, совместимое совпадение по одному и тому же почтовому почте и успешный вызов кода по электронной почте, а неудачные отправки кода проходили через ту же политику контроля вызовов и блокировки, что и рисковые OTP.