Объект Firebase Authentication user представляет аккаунт пользователя, который зарегистрировался в приложении в вашем проекте. У приложений обычно много зарегистрированных пользователей, и у всех приложений в проекте общая база данных пользователей.
Экземпляры пользователей независимы от экземпляров Firebase Authentication, поэтому в одном контексте можно иметь несколько ссылок на разных пользователей и вызывать любые их методы.
Свойства пользователя
Authentication у пользователей есть фиксированный набор основных свойств – уникальный идентификатор, основной адрес электронной почты, имя и URL фотографии, – которые хранятся в базе данных пользователей проекта и могут быть изменены пользователем (iOS, Android, веб). Добавлять другие свойства в объект пользователя напрямую нельзя. Вместо этого можно хранить дополнительные свойства в любых других сервисах хранения, например в Google Cloud Firestore.
Когда пользователь впервые регистрируется в приложении, его профиль заполняется на основе доступной информации:
- Если пользователь зарегистрировался, указав адрес электронной почты и пароль, заполняется только свойство основного адреса электронной почты.
- Если пользователь зарегистрировался с помощью федеративного поставщика идентификационной информации, например Google или Facebook, то для заполнения профиля используются данные, предоставленные этим поставщиком.
- Если пользователь зарегистрировался с помощью вашей системы аутентификации, вам нужно явно добавить в его профиль нужную информацию.
После создания аккаунта пользователя вы можете обновить его информацию, чтобы учесть изменения, которые пользователь мог внести на другом устройстве.
Провайдеры авторизации
Вы можете реализовать вход пользователей в приложения несколькими способами: с помощью адреса электронной почты и пароля, федеративных поставщиков идентификационной информации и собственной системы аутентификации. С одним аккаунтом можно связать несколько способов входа. Например, пользователь может входить в один и тот же аккаунт, используя адрес электронной почты и пароль или функцию "Войти с аккаунтом Google".
Экземпляры пользователей отслеживают каждого поставщика, связанного с пользователем. Это позволяет обновлять свойства пустых профилей, используя информацию, предоставленную поставщиком. Подробнее о том, как управлять пользователями, рассказывается в документации для iOS, Android и веб-версии.
Текущий пользователь
Когда пользователь регистрируется или входит в аккаунт, он становится текущим пользователем экземпляра Auth. Экземпляр сохраняет состояние пользователя, поэтому при обновлении страницы в браузере или перезапуске приложения информация о пользователе не теряется.
Когда пользователь выходит из аккаунта, экземпляр Auth перестает хранить ссылку на объект пользователя и его состояние. Текущего пользователя нет. Однако экземпляр пользователя остается полностью функциональным: если вы сохраните ссылку на него, то сможете и дальше получать доступ к данным пользователя и обновлять их.
Жизненный цикл пользователя
Рекомендуемый способ отслеживать текущее состояние экземпляра Auth – использовать прослушиватели (в JavaScript их также называют наблюдателями). Прослушиватель Auth получает уведомления о любых событиях, связанных с объектом Auth. Подробнее о том, как управлять пользователями, рассказывается в документации для iOS, Android и веб-приложений.
Прослушиватель Auth получает уведомления в следующих случаях:
- Объект Auth завершил инициализацию, и пользователь уже вошел в систему в предыдущем сеансе или был перенаправлен из процесса входа поставщика идентификационной информации.
- Пользователь входит в аккаунт (текущий пользователь задан).
- Пользователь выходит из аккаунта (текущий пользователь становится нулевым).
- Токен доступа текущего пользователя обновляется. Это может произойти в следующих случаях:
- Срок действия токена доступа истек. Это распространенная ситуация. Токен обновления используется для получения нового набора действительных токенов.
- Пользователь меняет пароль: Authentication выпускает новые токены доступа и обновления и делает старые токены недействительными. Это автоматически приводит к истечению срока действия токена пользователя и/или выходу из аккаунта на всех устройствах в целях безопасности.
- Пользователь повторно проходит аутентификацию. Для некоторых действий, например удаления аккаунта, установки основного адреса электронной почты и смены пароля, требуются недавно выданные учетные данные пользователя. Вместо того чтобы выходить из аккаунта пользователя и снова входить в него, получите новые учетные данные от пользователя и передайте их методу reauthenticate объекта пользователя.
Самостоятельное обслуживание пользователей
По умолчанию Firebase Authentication позволяет пользователям регистрироваться и удалять свои аккаунты без вмешательства администратора. Во многих случаях это позволяет конечным пользователям находить ваше приложение или сервис и быстро начинать или прекращать работу с ним.
Однако в некоторых случаях администратору может потребоваться создать аккаунты пользователей вручную или программно с помощью Admin SDK или консоли Firebase. В таких случаях вы можете отключить действия пользователей на странице Firebase Authentication Настройки, чтобы запретить создание и удаление аккаунтов конечными пользователями. Если вы используете многопользовательскую среду, вам нужно будет отправить HTTP-запрос, чтобы отключить эти функции для каждого клиента.
Если конечный пользователь попытается создать или удалить аккаунт в вашей системе, сервис Firebase Authentication вернет код ошибки: auth/admin-restricted-operation для вызовов Web API или ERROR_ADMIN_RESTRICTED_OPERATION для Android и iOS. Вам следует корректно обработать ошибку на стороне клиента, предложив пользователю выполнить необходимые действия.
Токены аутентификации
При аутентификации с помощью Authentication могут использоваться три типа токенов:
| Authentication токены идентификатора; | Создаются Authentication, когда пользователь входит в приложение. Эти токены представляют собой подписанные JWT, которые позволяют безопасно идентифицировать пользователя в проекте Firebase. Эти токены содержат основную информацию профиля пользователя, в том числе строку идентификатора пользователя, которая уникальна для проекта Firebase. Поскольку целостность токенов идентификатора можно проверить, их можно отправлять на внутренний сервер, чтобы идентифицировать пользователя, вошедшего в аккаунт. |
| Токены поставщика идентификационной информации | Создаются поставщиками федеративной идентификационной информации, например Google и Facebook. Эти токены могут иметь разные форматы, но часто это токены доступа OAuth 2.0. Приложения используют эти токены, чтобы убедиться, что пользователи успешно прошли аутентификацию у поставщика идентификационной информации, а затем преобразуют их в учетные данные, которые можно использовать в сервисах Authentication. |
| Authentication пользовательских токенов | Создается вашей системой аутентификации, чтобы пользователи могли входить в приложение с ее помощью. Специальные токены – это JWT, подписанные с помощью закрытого ключа сервисного аккаунта. Приложения используют эти токены так же, как и токены, возвращаемые поставщиками федеративной идентификационной информации. |
Подтвержденные адреса электронной почты
Authentication считает письмо проверенным, если оно соответствует двум условиям:
- Пользователь проходит проверку Authentication.
- Адрес электронной почты подтвержден надежным поставщиком идентификационной информации (IdP).
Поставщики идентификационной информации, которые проверяют адрес электронной почты один раз, а затем позволяют пользователям менять его без повторной проверки, не являются доверенными. Поставщики идентификационной информации, которые владеют доменом или всегда требуют подтверждения, считаются доверенными.
Надежные поставщики:
- Google (для адресов @gmail.com)
- Yahoo (для адресов @yahoo.com)
- Microsoft (для адресов @outlook.com и @hotmail.com)
- Apple (всегда подтвержден, так как аккаунты всегда подтверждаются и используется многофакторная аутентификация)
Ненадежные поставщики:
- GitHub
- Google, Yahoo и Microsoft для доменов, не выпущенных этим поставщиком идентификационной информации.
- Адрес электронной почты и пароль без подтверждения адреса электронной почты
В некоторых случаях Authentication автоматически связывает аккаунты, когда пользователь входит в них через разных поставщиков услуг, используя один и тот же адрес электронной почты. но только при соблюдении определенных условий. Чтобы понять, почему это происходит, рассмотрим следующую ситуацию: пользователь входит в аккаунт Google с адресом @gmail.com, а злоумышленник создает аккаунт с тем же адресом @gmail.com, но входит в него через Facebook. Если бы эти два аккаунта были связаны автоматически, злоумышленник получил бы доступ к аккаунту пользователя.
Ниже описаны случаи, когда мы автоматически связываем аккаунты и когда показываем ошибку, требующую действий от пользователя или разработчика.
- Пользователь входит в аккаунт с помощью ненадежного поставщика, а затем с помощью другого ненадежного поставщика, используя тот же адрес электронной почты (например, сначала через Facebook, а затем через GitHub). При этом возникает ошибка, требующая связать аккаунт.
- Пользователь входит в аккаунт через надежного поставщика, а затем через ненадежного, используя тот же адрес электронной почты (например, сначала через Google, а затем через Facebook). При этом возникает ошибка, требующая связать аккаунт.
- Пользователь входит в аккаунт с помощью ненадежного поставщика, а затем с помощью надежного поставщика, используя тот же адрес электронной почты (например, сначала через Facebook, а затем через Google). Надежный поставщик перезаписывает ненадежного. Если пользователь попытается войти в аккаунт с помощью Facebook, возникнет ошибка, требующая связать аккаунты.
- Пользователь входит в аккаунт с помощью одного доверенного поставщика, а затем с помощью другого, используя тот же адрес электронной почты (например, сначала через Apple, а затем через Google). Оба поставщика будут подключены без ошибок.
Вы можете вручную подтвердить адрес электронной почты с помощью Admin SDK, но мы рекомендуем делать это только в том случае, если вы уверены, что пользователь действительно владеет этим адресом.