Попытка понять Аутентификацию Firebase одна учетная запись на адрес электронной почты и доверенных поставщиков

Question

Если для Firebase Authentication в проекте Firebase включена одна учетная запись для каждого адреса электронной почты, то, похоже, существуют некоторые дополнительные правила, применимые к процессу аутентификации. Кажется, что разные провайдеры делятся на две категории: доверенные и ненадежные. Если в какой-либо момент пользователь входит в систему через доверенного поставщика, все ненадежные поставщики, с которыми пользователь ранее входил, удаляются из учетной записи. Кроме того, пользователь никогда не сможет войти в систему с ненадежным поставщиком. Является ли поставщик доверенным или ненадежным, кажется, зависит от того, проверяет ли новая учетная запись, созданная с поставщиком, исключительно эту учетную запись, отправляя подтверждающее электронное письмо на адрес, с которого была создана новая учетная запись.

Кажется, я не могу найти всеобъемлющего список относительно того, какие поставщики доверяют и не доверяют. Благодаря внедрению решений в мое приложение я нашел следующее:

ДОВЕРЕННЫЕ ПОСТАВЩИКИ:

• Apple
• Google
• Microsoft (если электронная почта, с которой была создана учетная запись, является @ outlook.com или @ hotmail.com)

Ненадежные поставщики:

• Facebook
• Microsoft (если электронная почта, с которой была создана учетная запись, не является @ outlook.com или @ hotmail.com)

Правильно ли это понимание? Где я могу найти разбивку по остальным поставщикам? Мое приложение встроено в Unity , поэтому я буду ограничен только поставщиками, поддерживающими Firebase в Unity. Почему Microsoft является доверенным и ненадежным поставщиком в различных обстоятельствах? Я мог бы действительно использовать некоторую помощь здесь.

Мое приложение для iOS и Android. Я хотел использовать только Apple и Google вход, но Apple вход недоступен для пользователей на iOS <13 </em>. Эти устройства iOS, по-видимому, представляют примерно шестую часть всех устройств в западных странах. Я пытался внедрить Google и Microsoft , чтобы получить хороший охват этих пользователей, но затем столкнулся с трудностью, когда Microsoft входил в список доверенных и недоверенных. , Я не хочу чрезмерно усложнять свое приложение ручным слиянием учетных записей, но я не знаю, каким другим поставщикам доверяют. Какое лучшее решение здесь, чтобы все было просто глупо?

Answer 1

Доверенные поставщики:

• Google (при условии, что он был выдан Google, например, @ gmail.com)
• Yahoo (при условии, что он был выдан Yahoo, например, @yahoo .com)
• Microsoft (при условии, что она была выпущена Microsoft, например, @ outlook.com)
• Apple (всегда проверено. Идея Apple состоит в том, что учетные записи проверены и многофакторная аутентификация) .
• Проверка подлинности ссылки электронной почты.

Ненадежные поставщики используют электронные письма, которые не были выданы поставщиком:

• Facebook
• Twitter
• GitHub
• Google, Yahoo, Microsoft и др. c при условии, что они не были выданы этим IdP.
• Электронная почта / пароль без подтверждения электронной почты

Firebase Auth делает это безопасно и не считает, что некоторые провайдеры проверены, поскольку в некоторых случаях электронная почта проверяется один раз, но не проверяется непрерывно (в некоторых случаях IdP позволяют изменять электронную почту после проверки без повторной проверки).

* 10 30 * Лучший способ объяснить чувствительность непроверенной учетной записи заключается в следующем: 1. Злоумышленник регистрируется у непроверенного провайдера (пароль), используя электронную почту victim@example.com, которой он не владеет 2. Владелец электронной почты регистрируется с victim@example.com, используя подтвержденный поставщик Google.

Если учетная запись не сброшена и пароль не связан, то злоумышленник сохраняет доступ к той учетной записи, которой он не владеет. Чтобы решить эту проблему, пользователь должен подтвердить электронную почту (отправив подтверждение по электронной почте) перед шагом 2. При этом вход в Google автоматически объединит учетные записи и сохранит пароль.

Именно поэтому в некоторых В некоторых случаях вы получите сообщение об ошибке:

1. Зарегистрируйтесь с непроверенным провайдером с помощью электронной почты user@example.com
2. Войдите с другим непроверенным провайдером того же адреса электронной почты
3. Ошибка выдается запрос на связывание после подтверждения владения первой учетной записью.
4. Ожидается, что пользователь войдет в учетную запись с шага 1.
5. Теперь пользователь может связать учетные данные учетной записи с шага 2.

Вот краткое описание поведения в различных случаях:

1. существующий непроверенный поставщик, войдите в систему с другим непроверенным поставщиком того же адреса электронной почты -> ошибка, требующая создания ссылки. (например, Facebook, а затем GitHub)
2. существующий проверенный поставщик, войдите в систему с другим непроверенным поставщиком того же адреса электронной почты -> ошибка, требующая создания ссылки. (например, Google и Facebook)
3. существующий непроверенный провайдер, войдите в систему с проверенным провайдером того же адреса электронной почты -> проверенный провайдер перезаписывает непроверенного провайдера. (например, Facebook, а затем Google)
4. существующий подтвержденный поставщик, войдите в систему с другим подтвержденным поставщиком того же адреса электронной почты -> Оба поставщика связались без ошибок. (например, Apple, затем Google)

Если вы не согласны с Firebase Auth и хотите считать Facebook проверенным провайдером, вы всегда можете настроить адрес электронной почты как проверенный после входа в Facebook, используя Admin SDK .

Надеюсь, это поможет прояснить это поведение.