Объект пользователя 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 позволяет пользователям регистрировать и удалять свои учетные записи без вмешательства администратора. Во многих случаях это позволяет конечным пользователям обнаружить ваше приложение или услугу и подключиться (или отключиться) с минимальными трудностями.
Однако бывают ситуации, когда вы хотите, чтобы администратор создавал пользователей вручную или программно, используя либо Admin SDK, либо консоль Firebase . В этих случаях вы можете отключить действия пользователя на странице настроек Firebase Authentication , что предотвращает создание и удаление учетной записи конечными пользователями. Если вы используете мультитенантность, вам нужно будет сделать HTTP-запрос , чтобы отключить эти функции для каждого арендатора.
Если конечный пользователь попытается создать или удалить учетную запись в вашей системе, служба Firebase вернет код ошибки: auth/admin-restricted-operation для вызовов веб-API или ERROR_ADMIN_RESTRICTED_OPERATION для Android и iOS. Вы должны корректно обработать ошибку во внешнем интерфейсе, попросив пользователя предпринять соответствующие действия для вашего сервиса.
Токены авторизации
Когда вы выполняете аутентификацию с помощью Firebase , вы можете столкнуться с тремя типами токенов аутентификации:
| Токены идентификатора Firebase | Создается Firebase , когда пользователь входит в приложение. Эти токены представляют собой подписанные JWT, которые надежно идентифицируют пользователя в проекте Firebase . Эти токены содержат основную информацию о профиле пользователя, включая строку идентификатора пользователя, которая уникальна для проекта Firebase . Поскольку целостность токенов идентификатора можно проверить , вы можете отправить их на внутренний сервер, чтобы идентифицировать текущего пользователя, вошедшего в систему. |
| Токены поставщика удостоверений | Создано федеративными поставщиками удостоверений, такими как Google и Facebook. Эти токены могут иметь разные форматы, но часто являются токенами доступа OAuth 2.0. Приложения используют эти токены для проверки того, что пользователи успешно прошли аутентификацию у поставщика удостоверений, а затем преобразуют их в учетные данные, которые могут использоваться службами Firebase . |
| Пользовательские токены Firebase | Создается вашей пользовательской системой аутентификации, чтобы пользователи могли входить в приложение с помощью вашей системы аутентификации. Пользовательские токены — это JWT , подписанные с использованием закрытого ключа сервисного аккаунта . Приложения используют эти токены так же, как они используют токены, возвращаемые федеративными поставщиками удостоверений. |
Подтвержденные адреса электронной почты
Firebase считает электронное письмо подтвержденным, если оно соответствует двум условиям:
- Пользователь завершает процесс проверки Firebase
- Электронная почта проверена надежным поставщиком удостоверений, или сокращенно IdP.
Поставщики удостоверений личности, которые проверяют электронную почту один раз, но затем позволяют пользователям менять адреса электронной почты без необходимости повторной проверки, не считаются доверенными. IdP, которые либо владеют доменом, либо всегда требуют проверки, считаются доверенными.
Доверенные поставщики:
- Google (для адресов @gmail.com)
- Yahoo (для адресов @yahoo.com)
- Microsoft (для адресов @outlook.com и @hotmail.com)
- Apple (всегда проверяется, поскольку учетные записи всегда проверяются и проходят многофакторную аутентификацию)
Ненадежные поставщики:
- Фейсбук
- Твиттер
- GitHub
- Google, Yahoo и Microsoft для доменов, не выданных этим поставщиком удостоверений.
- Электронная почта/пароль без проверки электронной почты
В некоторых ситуациях Firebase автоматически связывает учетные записи, когда пользователь входит в систему у разных провайдеров, используя один и тот же адрес электронной почты. Однако это может произойти только при соблюдении определенных критериев. Чтобы понять, почему, рассмотрим следующую ситуацию: пользователь входит в систему с помощью Google с учетной записью @gmail.com, а злоумышленник создает учетную запись, используя тот же адрес @gmail.com, но входит в систему через Facebook. Если бы эти две учетные записи были автоматически связаны, злоумышленник получил бы доступ к учетной записи пользователя.
Следующие случаи описывают случаи, когда мы автоматически связываем учетные записи и когда выдается ошибка, требующая действий пользователя или разработчика:
- Пользователь входит в систему у ненадежного поставщика, затем входит в систему у другого ненадежного поставщика с тем же адресом электронной почты (например, Facebook, а затем GitHub). Возникает ошибка, требующая привязки учетной записи.
- Пользователь входит в систему у доверенного поставщика, затем входит в систему у ненадежного поставщика с тем же адресом электронной почты (например, Google, а затем Facebook). Возникает ошибка, требующая привязки учетной записи.
- Пользователь входит в систему у ненадежного поставщика, затем входит в систему у доверенного поставщика с тем же адресом электронной почты (например, Facebook, а затем Google). Доверенный поставщик перезаписывает ненадежного поставщика. Если пользователь попытается снова войти в систему через Facebook, это приведет к ошибке, требующей привязки учетной записи.
- Пользователь входит в систему с помощью доверенного поставщика, затем входит в систему с другим доверенным поставщиком с тем же адресом электронной почты (например, Apple, а затем Google). Оба провайдера будут связаны без ошибок.
Вы можете вручную установить адрес электронной почты как подтвержденный с помощью Admin SDK, но мы рекомендуем делать это только в том случае, если вы уверены, что этот адрес электронной почты действительно принадлежит пользователю.