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

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

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

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

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

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

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

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

Поставщики входа

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

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

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

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

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

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

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

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

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

По умолчанию Firebase позволяет пользователям регистрироваться и удалять свои учетные записи без вмешательства администратора. Во многих случаях это позволяет конечным пользователям обнаружить ваше приложение или службу и установить их на борту (или за его пределами) с минимальными трудностями.

Однако бывают ситуации, когда вы хотите, чтобы администратор вручную или программно создавал пользователей с помощью Admin SDK или консоли Firebase. В этих случаях вы можете отключить действия пользователя на странице настроек аутентификации Firebase , что предотвратит создание и удаление учетной записи конечными пользователями. Если вы используете мультиарендность, вам нужно будет сделать HTTP-запрос , чтобы отключить эти функции для каждого арендатора.

Если конечный пользователь попытается создать или удалить учетную запись в вашей системе, служба Firebase вернет код ошибки: auth/admin-restricted-operation для вызовов веб-API или ERROR_ADMIN_RESTRICTED_OPERATION для Android и iOS. Вы должны изящно обработать ошибку на своем внешнем интерфейсе, попросив пользователя предпринять соответствующие действия для вашего сервиса.

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

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

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

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

Firebase считает электронное письмо проверенным, если оно соответствует двум условиям:

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

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

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

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

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

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

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

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

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

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