Firebase Auth: co to jest, metody uwierzytelniania i dostawcy logowania

Co to jest Firebase Auth

Firebase Auth to backendowa usługa Google do uwierzytelniania, dostępna w ramach Firebase SDK. Przejmuje całą serwerową logikę zarządzania kontami: przechowywanie hash haseł, generowanie tokenów JWT, obsługę protokołów OAuth 2.0 i OpenID Connect. Programista nie musi wdrażać własnego serwera auth, zarządzać tokenami odświeżania ani implementować protokołów weryfikacji — wszystko to robi Firebase.

Architektura usługi

Firebase Auth wykorzystuje architekturę federacyjną z jednym repozytorium użytkowników. Każdy użytkownik otrzymuje unikalny identyfikator (UID), który nie zależy od dostawcy logowania. Podczas rejestracji przez Google i e-mail tworzony jest jeden użytkownik z dwoma powiązanymi kontami (providers). Firebase automatycznie obsługuje łączenie kont (account linking) po stronie klienta bez dodatkowych zapytań do serwera.

Tokeny Firebase Auth to JWT (JSON Web Token) z payloadem zawierającym UID, czas wydania, czas wygaśnięcia i niestandardowe claims. Token dostępu żyje 1 godzinę, token odświeżania — bez ograniczeń (ale może być cofnięty przez Admin Console). SDK automatycznie odświeża token przy każdym żądaniu HTTP do usług Firebase. Według Google (2026), Firebase Auth obsługuje ponad 500 milionów uwierzytelnień dziennie.

Taryfy i limity

Firebase Auth jest całkowicie darmowy w taryfie Spark (bezpłatna) i Blaze (pay-as-you-go). Jedynym ograniczeniem jest 10 tysięcy anonimowych uwierzytelnień dziennie w Spark (w Blaze limit zniesiony). Uwierzytelnienia e-mail/telefon i OAuth nie mają limitów. W przypadku weryfikacji telefonicznej Spark udostępnia 10 tysięcy weryfikacji miesięcznie, w Blaze — płatność według użycia ($0.01 za weryfikację po wyczerpaniu 10 tysięcy). To czyni Firebase Auth jednym z najbardziej dostępnych rozwiązań na rynku.

Dostawcy uwierzytelniania Firebase Auth

Firebase Auth obsługuje 12 dostawców uwierzytelniania od razu po wyjęciu z pudełka. Każdy dostawca jest zaimplementowany jako osobna usługa tożsamości z określonym przepływem — programista musi tylko utworzyć obiekt Credential i przekazać go do signInWithCredential. Firebase automatycznie określa, czy to nowy użytkownik, czy istniejący, a w przypadku duplikacji e-maila proponuje połączenie kont.

E-mail i hasło

E-mail/Hasło — podstawowa metoda uwierzytelniania z przechowywaniem hash haseł (bcrypt) na serwerach Firebase. Obsługiwana jest rejestracja, logowanie, resetowanie hasła przez e-mail i potwierdzenie e-maila. Firebase automatycznie sprawdza złożoność hasła (minimum 6 znaków) i może blokować logowanie po N nieudanych próbach (ochrona przed brute-force).

Dostawcy społecznościowi

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — wszyscy dostawcy OAuth 2.0 konfigurują się przez konsolę Firebase w 5 minut. Dla każdego dostawcy należy uzyskać Client ID i Client Secret w konsoli samego dostawcy. Apple Sign In jest obowiązkowy dla aplikacji w App Store (wymóg Apple od 2020 roku). Firebase Auth w pełni obsługuje przepływ Apple Sign In z weryfikacją JWT.

Uwierzytelnianie telefoniczne

Phone Auth — uwierzytelnianie za pomocą kodu SMS wysyłanego na numer telefonu użytkownika. Firebase wykorzystuje Silent APN (iOS) lub SMS Retriever API (Android) do automatycznego odczytu kodu bez wpisywania z klawiatury. W Androidzie SMS Retriever API działa tylko na urządzeniach z Google Play Services. Dla regionów, w których SMS jest niedostępny, Firebase obsługuje weryfikację reCAPTCHA jako fallback. Uwierzytelnianie telefoniczne jest kluczowe dla aplikacji z obowiązkowym przypisaniem do numeru — dostawa jedzenia, taksówki, bankowość.

Integracja Firebase Auth w Android

Podłączenie Firebase Auth w Androidzie wymaga dodania zależności firebase-auth-ktx do build.gradle i inicjalizacji Firebase App (wykonywanej automatycznie przez Google Services plugin). Następnie obiekt FirebaseAuth jest dostępny za pomocą statycznej metody getInstance() — singleton na całą aplikację. Żadna dodatkowa konfiguracja nie jest wymagana.

// build.gradle (poziom aplikacji)
dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-auth-ktx")
    implementation("com.google.android.gms:play-services-auth:21.0.0")
}

Rejestracja użytkownika przez e-mail

createUserWithEmailAndPassword — główna metoda rejestracji. Przyjmuje e-mail i hasło, tworzy użytkownika w Firebase Auth i zwraca obiekt AuthResult z UID. Jeśli użytkownik z takim e-mailem już istnieje, Firebase zwraca błąd ERROR_EMAIL_ALREADY_IN_USE. Po pomyślnej rejestracji SDK automatycznie zapisuje token w SharedPreferences i przy następnym uruchomieniu aplikacji przywraca sesję bez wywoływania signIn.

class AuthViewModel {
    private val auth = FirebaseAuth.getInstance()

    suspend fun register(email: String, password: String): Result<User> {
        return try {
            val result = auth.createUserWithEmailAndPassword(email, password).await()
            Result.success(result.user?.toUser() ?: throw Exception("User is null"))
        } catch (e: FirebaseAuthException) {
            Result.failure(e)
        }
    }
}

Logowanie przez Google

Do Google Sign In wykorzystywany jest dwuetapowy proces: uzyskanie ID Token przez Credential Manager (Android) lub Google Sign-In SDK, a następnie przekazanie tokena do Firebase credential. Firebase weryfikuje token na swoim serwerze (sprawdza podpis kluczem RSA Google) i tworzy lub zwraca istniejącego użytkownika. Proces nie wymaga przechowywania secret na kliencie — całe uwierzytelnianie odbywa się przez kryptograficzną weryfikację tokenów.

Zarządzanie użytkownikami i sesjami

Firebase Auth automatycznie zarządza cyklem życia sesji. Po zalogowaniu SDK zapisuje token odświeżania w lokalnym magazynie, a przy każdym ponownym uruchomieniu aplikacji przywraca sesję przez signIn silently. Programista nie musi implementować przechowywania tokena, obsługi jego wygaśnięcia ani odświeżania — wszystko robi Firebase Auth SDK.

Aktualny użytkownik

FirebaseAuth.getInstance().currentUser zwraca obiekt FirebaseUser, jeśli sesja jest aktywna, lub null, jeśli użytkownik się wylogował. FirebaseUser zawiera UID, e-mail, displayName, photoUrl, phoneNumber, providerData i listę claims. Po aktualizacji profilu (updateProfile) zmiany są synchronizowane z serwerem automatycznie. Obiekt FirebaseUser jest buforowany w pamięci i aktualizowany przy wszelkich operacjach auth.

Uwierzytelnianie anonimowe

signInAnonymously — tworzy tymczasowego użytkownika bez rejestracji. Anonimowi użytkownicy mają UID, ale nie mają e-maila, nazwy ani dostawcy. Jest to przydatne w aplikacjach, gdzie treść jest dostępna przed rejestracją (koszyk, ulubione, historia). Gdy użytkownik zdecyduje się zarejestrować, anonimowe konto jest łączone ze stałym przez linkWithCredential. W taryfie Spark obowiązuje limit 10 tysięcy anonimowych uwierzytelnień dziennie.

Według Google (2026), około 40% użytkowników zaczyna pracę z aplikacją anonimowo, a 25% z nich następnie łączy anonimowe konto ze stałym. Oznacza to, że uwierzytelnianie anonimowe nie traci danych przy konwersji użytkownika na zarejestrowanego.

Wylogowanie i usunięcie konta

Metoda signOut() czyści lokalną sesję i usuwa zapisany token. Po wywołaniu signOut currentUser staje się null. Metoda delete() usuwa konto użytkownika całkowicie z Firebase Auth — wszyscy powiązani dostawcy są odłączani, a dostęp do usług Firebase jest blokowany. Usunięcie użytkownika jest nieodwracalne i wymaga ponownego uwierzytelnienia (reauthenticate) w celu ochrony przed nieautoryzowanym usunięciem konta.

Niestandardowe claims i zarządzanie rolami

Custom Claims to niestandardowe atrybuty, które Firebase Auth dodaje do tokena JWT użytkownika. W przeciwieństwie do standardowych pól profilu (e-mail, displayName), claims są dostępne tylko po stronie serwerowej — przez Admin SDK lub przez reguły w Firebase Security Rules dla Firestore i Realtime Database. Claims nie są widoczne dla klienta bezpośrednio, ale mogą być odczytane przez user.getIdTokenResult().

Typowe scenariusze użycia

Role i uprawnienia dostępu — najczęstszy scenariusz zastosowania claims. Admin SDK umożliwia przypisanie roli „admin”, „moderator” lub „premium_user” przez mapę na serwerze. Te claims automatycznie trafiają do tokena i mogą być używane w Firestore Security Rules do rozgraniczenia dostępu. Według Google (2026), 65% projektów Firebase używa custom claims do zarządzania dostępem do danych zamiast oddzielnego serwera ról.

// Admin SDK (Node.js) — przypisywanie claims użytkownikowi
const admin = require("firebase-admin")

await admin.auth().setCustomUserClaims(uid, {
    role: "premium",
    tier: "pro",
    maxProjects: 50
})

// Odczyt claims po stronie klienta
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Ograniczenia claims

Custom claims mają ograniczenia: maksymalnie 1000 bajtów na cały obiekt JSON claims na użytkownika, nie więcej niż 20 kluczy w obiekcie. Claims nie są przeznaczone do przechowywania danych dynamicznych — są aktualizowane tylko przez Admin SDK i nie synchronizują się w czasie rzeczywistym. Po aktualizacji claims użytkownik musi odświeżyć token (getIdTokenResult(true)) lub zalogować się ponownie. Claims nie są buforowane po stronie klienta — każde nowe logowanie otrzymuje aktualny token z serwera.

Bezpieczeństwo uwierzytelniania

Firebase Auth implementuje wielopoziomową ochronę kont: szyfrowanie ruchu (TLS 1.3), haszowanie haseł (bcrypt, koszt 10), ochronę przed brute-force z Adaptive Pricing (automatyczne spowalnianie odpowiedzi przy podejrzanej aktywności) i integrację z reCAPTCHA dla logowania webowego. Dodatkowo Firebase Auth wyłącza konta przy podejrzanej aktywności — masowe logowania z różnych IP, próby logowania z nieprawidłowym hasłem i podejrzane adresy e-mail.

Metody ochrony

Account Lockout — automatyczna blokada konta po określonej liczbie nieudanych prób logowania. Próg jest konfigurowalny w konsoli Firebase (domyślnie 10 prób). Email Enumeration Protection — ochrona przed przeszukiwaniem adresów e-mail. Po włączeniu Firebase zwraca ten sam błąd zarówno dla istniejącego, jak i nieistniejącego e-maila. Trusted Domains — ograniczenie logowania tylko dla użytkowników z domenami e-mail wskazanymi w ustawieniach.

Bezpieczeństwo niestandardowych tokenów

Dodatkowe niestandardowe uwierzytelnianie można zbudować na Custom Tokens — JWT podpisanych kontem serwisowym Firebase. Klient przekazuje niestandardowy token do signInWithCustomToken(), Firebase weryfikuje podpis i tworzy sesję. Umożliwia to integrację Firebase Auth z istniejącym uwierzytelnianiem serwerowym (np. OAuth 2.0 własnego serwera) bez duplikowania bazy użytkowników. Token żyje 1 godzinę, po czym SDK automatycznie odświeża sesję przez token odświeżania Firebase.