Obiekt Firebase Authentication user reprezentuje konto użytkownika, który zarejestrował się w aplikacji w Twoim projekcie. Aplikacje mają zwykle wielu zarejestrowanych użytkowników, a każda aplikacja w projekcie korzysta z tej samej bazy danych użytkowników.
Instancje użytkowników są niezależne od Firebase Authentication instancji, więc możesz mieć kilka odwołań do różnych użytkowników w tym samym kontekście i nadal wywoływać dowolne z ich metod.
Właściwości użytkownika
Authentication użytkownicy mają stały zestaw podstawowych właściwości – unikalny identyfikator, podstawowy adres e-mail, nazwę i adres URL zdjęcia – przechowywanych w bazie danych użytkowników projektu, które mogą być aktualizowane przez użytkownika (iOS, Android, internet). Nie możesz bezpośrednio dodawać innych właściwości do obiektu użytkownika. Zamiast tego możesz przechowywać dodatkowe właściwości w dowolnych innych usługach pamięci masowej, takich jak Google Cloud Firestore.
Gdy użytkownik po raz pierwszy zarejestruje się w Twojej aplikacji, dane profilu użytkownika zostaną wypełnione dostępnymi informacjami:
- Jeśli użytkownik zarejestrował się za pomocą adresu e-mail i hasła, wypełniana jest tylko właściwość podstawowego adresu e-mail.
- Jeśli użytkownik zarejestrował się za pomocą federacyjnego dostawcy tożsamości, takiego jak Google czy Facebook, do wypełnienia profilu użytkownika używane są informacje o koncie udostępnione przez dostawcę.
- Jeśli użytkownik zarejestrował się za pomocą niestandardowego systemu uwierzytelniania, musisz wyraźnie dodać informacje, które chcesz umieścić w profilu użytkownika.
Po utworzeniu konta użytkownika możesz ponownie wczytać informacje o użytkowniku, aby uwzględnić wszelkie zmiany, które użytkownik mógł wprowadzić na innym urządzeniu.
Dostawcy logowania
Użytkownicy mogą logować się w Twoich aplikacjach na kilka sposobów: za pomocą adresu e-mail i hasła, federacyjnych dostawców tożsamości oraz niestandardowego systemu uwierzytelniania. Możesz powiązać z użytkownikiem więcej niż 1 metodę logowania. Na przykład użytkownik może logować się na to samo konto za pomocą adresu e-mail i hasła lub za pomocą logowania przez Google.
Instancje użytkowników śledzą każdego dostawcę powiązanego z użytkownikiem. Dzięki temu możesz aktualizować puste właściwości profilu za pomocą informacji podanych przez dostawcę. Więcej informacji znajdziesz w artykule Zarządzanie użytkownikami (iOS, Android, internet).
Obecny użytkownik
Gdy użytkownik zarejestruje się lub zaloguje, staje się obecnym użytkownikiem instancji Auth. Instancja zachowuje stan użytkownika, dzięki czemu odświeżenie strony (w przeglądarce) lub ponowne uruchomienie aplikacji nie powoduje utraty informacji o użytkowniku.
Gdy użytkownik się wyloguje, instancja Auth przestaje przechowywać odwołanie do obiektu użytkownika i nie zachowuje już jego stanu. Nie ma obecnego użytkownika. Instancja użytkownika nadal jest jednak w pełni funkcjonalna. Jeśli zachowasz do niej odwołanie, nadal możesz uzyskiwać dostęp do danych użytkownika i je aktualizować.
Cykl życia użytkownika
Zalecanym sposobem śledzenia bieżącego stanu instancji Auth jest używanie detektorów (w JavaScript nazywanych też „obserwatorami”). Detektor Auth otrzymuje powiadomienie za każdym razem, gdy w obiekcie Auth dzieje się coś istotnego. Więcej informacji znajdziesz w artykule Zarządzanie użytkownikami (iOS, Android, internet).
Detektor Auth otrzymuje powiadomienie w tych sytuacjach:
- Obiekt Auth kończy inicjowanie i użytkownik był już zalogowany w poprzedniej sesji lub został przekierowany z procesu logowania dostawcy tożsamości.
- Użytkownik się loguje (ustawiany jest obecny użytkownik).
- Użytkownik się wylogowuje (obecny użytkownik staje się wartością null).
- Token dostępu obecnego użytkownika jest odświeżany. Może się to zdarzyć w tych sytuacjach:
- Token dostępu wygasa. Jest to częsta sytuacja. Token odświeżania służy do uzyskania nowego, prawidłowego zestawu tokenów.
- Użytkownik zmienia hasło. Authentication wydaje nowe tokeny dostępu i odświeżania oraz unieważnia stare tokeny. Ze względów bezpieczeństwa powoduje to automatyczne wygaśnięcie tokena użytkownika lub wylogowanie użytkownika na każdym urządzeniu.
- Użytkownik ponownie się uwierzytelnia. Niektóre działania wymagają, aby dane logowania użytkownika zostały wydane niedawno. Należą do nich usuwanie konta, ustawianie podstawowego adresu e-mail i zmiana hasła. Zamiast wylogowywać użytkownika, a potem logować go ponownie, poproś go o nowe dane logowania i przekaż je do metody reauthenticate obiektu użytkownika.
Samodzielne zarządzanie użytkownikami
Domyślnie Firebase Authentication umożliwia użytkownikom rejestrowanie się i usuwanie kont bez interwencji administratora. W wielu przypadkach umożliwia to użytkownikom odkrywanie Twojej aplikacji lub usługi oraz rejestrowanie się (lub wyrejestrowywanie) bez większych problemów.
Są jednak sytuacje, w których chcesz, aby użytkownicy byli tworzeni ręcznie lub programowo przez administratora za pomocą pakietu Admin SDK lub Firebase konsoli. W takich przypadkach możesz wyłączyć działania użytkowników na stronie Firebase Authentication ustawień , co uniemożliwi użytkownikom tworzenie i usuwanie kont. Jeśli używasz wielu najemców, musisz wysłać żądanie HTTP aby wyłączyć te funkcje dla każdego najemcy.
Jeśli użytkownik spróbuje utworzyć lub usunąć konto w Twoim systemie, usługa
Firebase Authentication zwróci kod błędu:
auth/admin-restricted-operation w przypadku wywołań Web API lub ERROR_ADMIN_RESTRICTED_OPERATION w przypadku Androida i iOS. Powinieneś odpowiednio obsłużyć ten błąd w interfejsie, prosząc użytkownika o wykonanie odpowiednich działań w Twojej usłudze.
Tokeny uwierzytelniania
Podczas uwierzytelniania za pomocą Authentication możesz spotkać się z 3 rodzajami tokenów uwierzytelniania:
| Tokeny identyfikacyjne Authentication | Tworzone przez Authentication, gdy użytkownik loguje się w aplikacji. Te tokeny to podpisane tokeny JWT, które bezpiecznie identyfikują użytkownika w Firebase projekcie. Zawierają one podstawowe informacje o profilu użytkownika, w tym ciąg identyfikatora użytkownika, który jest unikalny dla projektu. Firebase Ponieważ można zweryfikować integralność tokenów identyfikacyjnych, możesz wysyłać je do serwera backendu, aby zidentyfikować aktualnie zalogowanego użytkownika. |
| Tokeny dostawcy tożsamości | Tworzone przez federacyjnych dostawców tożsamości, takich jak Google i Facebook. Tokeny te mogą mieć różne formaty, ale często są to tokeny dostępu OAuth 2.0 tokeny. Aplikacje używają tych tokenów, aby sprawdzić, czy użytkownicy pomyślnie uwierzytelnili się u dostawcy tożsamości, a następnie przekształcają je w dane logowania, które mogą być używane przez usługi Authentication. |
| Tokeny niestandardowe Authentication | Tworzone przez niestandardowy system uwierzytelniania, aby umożliwić użytkownikom logowanie się w aplikacji za pomocą tego systemu. Tokeny niestandardowe to tokeny JWT podpisane kluczem prywatnym konta usługi. Aplikacje używają tych tokenów podobnie jak tokenów zwracanych przez dostawców tożsamości sfederowanej. |
Zweryfikowane adresy e-mail
Authentication uznaje adres e-mail za zweryfikowany, jeśli spełnia on 2 warunki:
- Użytkownik przechodzi proces weryfikacji Authentication.
- Adres e-mail jest zweryfikowany przez zaufanego dostawcę tożsamości.
Dostawcy tożsamości, którzy weryfikują adres e-mail tylko raz, a potem pozwalają użytkownikom zmieniać adresy e-mail bez konieczności ponownej weryfikacji, nie są zaufani. Za zaufanych uznaje się dostawców tożsamości, którzy są właścicielami domeny lub zawsze wymagają weryfikacji.
Zaufani dostawcy:
- Google (w przypadku adresów @gmail.com)
- Yahoo (w przypadku adresów @yahoo.com)
- Microsoft (w przypadku adresów @outlook.com i @hotmail.com)
- Apple (zawsze zweryfikowany, ponieważ konta są zawsze zweryfikowane i uwierzytelnione wielopoziomowo)
Niezaufani dostawcy:
- GitHub
- Google, Yahoo i Microsoft w przypadku domen, które nie zostały wydane przez tego dostawcę tożsamości
- Adres e-mail / hasło bez potwierdzania adresu e-mail
W niektórych sytuacjach Authentication automatycznie łączy konta, gdy użytkownik loguje się u różnych dostawców za pomocą tego samego adresu e-mail. Może się to jednak zdarzyć tylko wtedy, gdy zostaną spełnione określone kryteria. Aby to zrozumieć, rozważ następującą sytuację: użytkownik loguje się za pomocą Google na konto @gmail.com, a nieuczciwy podmiot tworzy konto, używając tego samego adresu @gmail.com, ale logując się przez Facebooka. Jeśli te 2 konta zostałyby połączone automatycznie, nieuczciwy podmiot uzyskałby dostęp do konta użytkownika.
Poniższe przypadki opisują, kiedy automatycznie łączymy konta, a kiedy zgłaszamy błąd wymagający działania użytkownika lub dewelopera:
- Użytkownik loguje się u niezaufanego dostawcy, a następnie loguje się u innego niezaufanego dostawcy za pomocą tego samego adresu e-mail (np. Facebook, a potem GitHub). Powoduje to zgłoszenie błędu wymagającego połączenia kont.
- Użytkownik loguje się u zaufanego dostawcy, a następnie loguje się u niezaufanego dostawcy za pomocą tego samego adresu e-mail (np. Google, a potem Facebook). Powoduje to zgłoszenie błędu wymagającego połączenia kont.
- Użytkownik loguje się u niezaufanego dostawcy, a następnie loguje się u zaufanego dostawcy za pomocą tego samego adresu e-mail (np. Facebook, a potem Google). Zaufany dostawca zastępuje niezaufanego. Jeśli użytkownik spróbuje ponownie zalogować się za pomocą Facebooka, spowoduje to błąd wymagający połączenia kont.
- Użytkownik loguje się u zaufanego dostawcy, a następnie loguje się u innego zaufanego dostawcy za pomocą tego samego adresu e-mail (np. Apple, a potem Google). Obaj dostawcy zostaną połączeni bez błędów.
Możesz ręcznie ustawić adres e-mail jako zweryfikowany za pomocą pakietu Admin SDK, ale zalecamy, aby robić to tylko wtedy, gdy masz pewność, że użytkownik jest właścicielem tego adresu e-mail.