Пользователи в проектах Firebase

Объект пользователя Firebase представляет учетную запись пользователя , который подписался на приложение в вашем проекте. У приложений обычно много зарегистрированных пользователей, и каждое приложение в проекте использует базу данных пользователей.

Пользовательские экземпляры не зависят от экземпляров Firebase Authentication, поэтому вы можете иметь несколько ссылок на разных пользователей в одном контексте и при этом вызывать любой из их методов.

Свойства пользователя

Firebase пользователи имеют фиксированный набор основных свойств, уникальный идентификатор, основной адрес электронной почты, имя и фотография URL сохраненное в пользовательской базе данных проекта, которые могут быть обновлены пользователем ( IOS , Android , веб ). Вы не можете напрямую добавлять другие свойства к пользовательскому объекту; вместо этого вы можете хранить дополнительные свойства в любых других службах хранения, например Google Cloud Firestore.

При первой регистрации пользователя в вашем приложении данные профиля пользователя заполняются с использованием доступной информации:

  • Если пользователь зарегистрировался с адресом электронной почты и паролем, заполняется только свойство основного адреса электронной почты.
  • Если пользователь зарегистрировался у федеративного поставщика удостоверений, такого как Google или Facebook, информация об учетной записи, предоставленная поставщиком, используется для заполнения профиля пользователя.
  • Если пользователь зарегистрировался в вашей настраиваемой системе аутентификации, вы должны явно добавить нужную информацию в профиль пользователя.

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

Поставщики услуг входа

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

Экземпляры пользователей отслеживают каждого поставщика, связанного с пользователем. Это позволяет вам обновлять свойства пустого профиля, используя информацию, предоставленную провайдером. См Управления пользователей ( IOS , Android , веб ).

Текущий пользователь

Когда пользователь регистрируется или входит в систему, этот пользователь становится текущим пользователем экземпляра Auth. Экземпляр сохраняет состояние пользователя, поэтому при обновлении страницы (в браузере) или перезапуске приложения информация о пользователе не теряется.

Когда пользователь выходит из системы, экземпляр Auth перестает сохранять ссылку на пользовательский объект и больше не сохраняет свое состояние; нет текущего пользователя. Однако пользовательский экземпляр продолжает оставаться полностью функциональным: если вы сохраните ссылку на него, вы все равно сможете получить доступ и обновить данные пользователя.

Жизненный цикл пользователя

Рекомендуемый способ отслеживать текущее состояние экземпляра Auth - использовать слушателей (также называемых «наблюдателями» в JavaScript). Слушатель Auth получает уведомление каждый раз, когда с объектом Auth происходит что-то важное. См Управления пользователей ( IOS , Android , веб ).

Слушатель Auth получает уведомление в следующих ситуациях:

  • Объект Auth завершает инициализацию, и пользователь уже вошел в систему из предыдущего сеанса или был перенаправлен из потока входа поставщика удостоверений.
  • Пользователь входит в систему (текущий пользователь установлен)
  • Пользователь выходит из системы (текущий пользователь становится пустым)
  • Токен доступа текущего пользователя обновляется. Этот случай может произойти в следующих условиях:
    • Срок действия токена доступа истекает: это обычная ситуация. Токен обновления используется для получения нового действительного набора токенов.
    • Пользователь меняет свой пароль: Firebase выдает новые токены доступа и обновления, а срок действия старых токенов истек. Это автоматически истекает токен пользователя и / или выводит пользователя из системы на каждом устройстве по соображениям безопасности.
    • Пользователь повторно аутентифицируется: для некоторых действий требуется, чтобы учетные данные пользователя были выданы недавно; такие действия включают удаление учетной записи, установку основного адреса электронной почты и изменение пароля. Вместо того, чтобы выходить из системы и затем снова входить в систему, получите новые учетные данные от пользователя и передайте новые учетные данные методу повторной аутентификации объекта пользователя.

Токены аутентификации

Когда вы выполняете аутентификацию с помощью Firebase, вы можете встретить три типа токенов аутентификации:

Токены Firebase ID Создается Firebase, когда пользователь входит в приложение. Эти токены представляют собой подписанные JWT, которые надежно идентифицируют пользователя в проекте Firebase. Эти токены содержат основную информацию профиля пользователя, включая строку идентификатора пользователя, которая уникальна для проекта Firebase. Поскольку целостность идентификационных маркеров может быть проверена , вы можете отправить их на внутренний сервер для идентификации текущего зарегистрированны пользователя.
Токены поставщика удостоверений Создано федеративными поставщиками удостоверений, такими как Google и Facebook. Эти токены могут иметь разные форматы, но часто являются токенами доступа OAuth 2.0. Приложения используют эти токены для проверки того, что пользователи успешно прошли аутентификацию с помощью поставщика удостоверений, а затем конвертируют их в учетные данные, используемые службами Firebase.
Пользовательские токены Firebase Создано вашей пользовательской системой аутентификации, чтобы пользователи могли входить в приложение, используя вашу систему аутентификации. Пользовательские жетоны JWTs подписанный с использованием секретного ключа учетной записи услуг . Приложения используют эти токены так же, как они используют токены, возвращенные от федеративных поставщиков удостоверений.

Проверенные адреса электронной почты

Firebase считает электронную почту подтвержденной, если она соответствует двум условиям: 1. Пользователь завершает процесс проверки Firebase. 2. Электронная почта проверяется доверенным поставщиком удостоверений, или для краткости IdP.

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

Проверенные провайдеры:

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

Недоверенные провайдеры:

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

В некоторых ситуациях Firebase автоматически связывает учетные записи, когда пользователь входит в систему у разных поставщиков, используя один и тот же адрес электронной почты. Однако это может произойти только при соблюдении определенных критериев. Чтобы понять, почему, рассмотрим следующую ситуацию: пользователь входит в систему с помощью Google с учетной записью @ gmail.com, а злоумышленник создает учетную запись, используя тот же адрес @ gmail.com, но входя через Facebook. Если бы эти две учетные записи были автоматически связаны, злоумышленник получил бы доступ к учетной записи пользователя.

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

  • Пользователь входит в систему с помощью ненадежного поставщика, а затем входит в систему с помощью другого ненадежного поставщика с тем же адресом электронной почты (например, Facebook, а затем GitHub). Это вызывает ошибку, требующую привязки учетной записи.
  • Пользователь входит в систему с помощью доверенного поставщика, а затем входит в систему с помощью ненадежного поставщика с тем же адресом электронной почты (например, Google, а затем Facebook). Это вызывает ошибку, требующую привязки учетной записи.
  • Пользователь входит в систему с помощью ненадежного поставщика, а затем входит в систему с помощью доверенного поставщика с тем же адресом электронной почты (например, Facebook, а затем Google). Доверенный поставщик перезаписывает ненадежного поставщика. Если пользователь попытается снова войти в систему с помощью Facebook, это вызовет ошибку, требующую привязки учетной записи.
  • Пользователь входит в систему с помощью доверенного поставщика, а затем входит в систему с помощью другого надежного поставщика с тем же адресом электронной почты (например, Apple, а затем Google). Оба провайдера будут связаны без ошибок.

Вы можете вручную настроить электронную почту как подтвержденную с помощью Admin SDK, но мы рекомендуем делать это только в том случае, если вы знаете, что пользователю действительно принадлежит электронная почта.