Объект пользователя Firebase Authentication представляет собой учетную запись пользователя, зарегистрировавшегося в приложении вашего проекта. В приложениях обычно зарегистрировано много пользователей, и каждое приложение в проекте использует общую базу данных пользователей.
Экземпляры пользователей независимы от экземпляров Firebase Authentication , поэтому вы можете иметь несколько ссылок на разных пользователей в одном контексте и при этом вызывать любые их методы.
Свойства пользователя
Authentication пользователи имеют фиксированный набор основных свойств — уникальный идентификатор, основной адрес электронной почты, имя и URL-адрес фотографии — которые хранятся в базе данных пользователей проекта и могут быть обновлены пользователем ( iOS , Android , web ). Добавить другие свойства к объекту пользователя напрямую нельзя; вместо этого дополнительные свойства можно хранить в любых других сервисах хранения, например, в Google Cloud Firestore.
При первой регистрации пользователя в вашем приложении данные его профиля заполняются с использованием имеющейся информации:
- Если пользователь зарегистрировался с помощью адреса электронной почты и пароля, заполняется только поле "Основной адрес электронной почты".
- Если пользователь зарегистрировался через федеративного поставщика идентификации, такого как Google или Facebook, информация об учетной записи, предоставленная этим поставщиком, используется для заполнения профиля пользователя.
- Если пользователь зарегистрировался с помощью вашей собственной системы аутентификации, вам необходимо явно добавить необходимую информацию в профиль пользователя.
После создания учетной записи пользователя вы можете обновить его данные, чтобы учесть любые изменения, внесенные им на другом устройстве.
Поставщики услуг авторизации
Вы можете авторизовать пользователей в своих приложениях несколькими способами: с помощью адреса электронной почты и пароля, федеративных провайдеров идентификации и вашей собственной системы аутентификации. С пользователем можно связать несколько способов авторизации: например, пользователь может войти в одну и ту же учетную запись, используя адрес электронной почты и пароль, или с помощью Google Sign-In.
Экземпляры пользователей отслеживают всех поставщиков услуг, связанных с пользователем. Это позволяет обновлять свойства пустого профиля, используя информацию, предоставленную поставщиком. См. раздел «Управление пользователями» ( iOS , Android , веб ).
Текущий пользователь
Когда пользователь регистрируется или входит в систему, он становится текущим пользователем экземпляра Auth. Экземпляр сохраняет состояние пользователя, поэтому обновление страницы (в браузере) или перезапуск приложения не приводят к потере информации о пользователе.
Когда пользователь выходит из системы, экземпляр Auth перестаёт хранить ссылку на объект пользователя и больше не сохраняет его состояние; текущего пользователя нет. Однако экземпляр пользователя остаётся полностью функциональным: если вы сохраняете ссылку на него, вы всё ещё можете получить доступ к данным пользователя и обновить их.
Жизненный цикл пользователя
Рекомендуемый способ отслеживания текущего состояния экземпляра Auth — использование слушателей (также называемых «наблюдателями» в JavaScript). Слушатель Auth получает уведомление всякий раз, когда с объектом Auth происходит что-то важное. См. раздел «Управление пользователями» ( iOS , Android , web ).
Слушатель аутентификации получает уведомление в следующих ситуациях:
- Объект 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 ID | Эти токены создаются в процессе Authentication при входе пользователя в приложение. Они представляют собой подписанные JWT-токены, которые обеспечивают безопасную идентификацию пользователя в проекте Firebase . Токены содержат основную информацию профиля пользователя, включая идентификационную строку, уникальную для проекта Firebase . Поскольку целостность идентификационных токенов может быть проверена , их можно отправлять на серверную часть для идентификации текущего вошедшего в систему пользователя. |
| Токены поставщика идентификационных данных | Эти токены создаются федеративными поставщиками идентификации, такими как Google и Facebook. Они могут иметь разные форматы, но часто представляют собой токены доступа OAuth 2.0. Приложения используют эти токены для проверки успешной аутентификации пользователей у поставщика идентификации, а затем преобразуют их в учетные данные, используемые службами Authentication . |
| Пользовательские токены Authentication | Создаются вашей пользовательской системой аутентификации, чтобы позволить пользователям входить в приложение, используя вашу систему аутентификации. Пользовательские токены — это JWT , подписанные с использованием закрытого ключа учетной записи службы . Приложения используют эти токены так же, как и токены, возвращаемые федеративными поставщиками идентификации. |
Подтвержденные адреса электронной почты
Authentication считает электронный адрес подтвержденным, если он соответствует двум условиям:
- Пользователь завершает процесс проверки Authentication
- Адрес электронной почты проверяется доверенным поставщиком идентификационных данных (IdP).
Поставщики идентификации (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, но мы рекомендуем делать это только в том случае, если вы уверены, что пользователь действительно является владельцем этого адреса.