Firebase Auth: vad det är, autentiseringsmetoder och inloggningsleverantörer

Vad är Firebase Auth

Firebase Auth är en backend-tjänst från Google för autentisering, som tillhandahålls som en del av Firebase SDK. Den tar över all serverlogik för kontohantering: lagring av lösenordshashar, generering av JWT-tokens, bearbetning av OAuth 2.0- och OpenID Connect-flöden. Utvecklaren behöver inte sätta upp en egen auth-server, hantera refresh-tokens eller implementera verifieringsprotokoll — allt detta görs av Firebase.

Tjänstens arkitektur

Firebase Auth använder en federativ arkitektur med en enhetlig användarlagring. Varje användare får en unik identifierare (UID) som inte är beroende av inloggningsleverantören. Vid registrering via Google och e-post skapas en användare med två kopplade konton (providers). Firebase hanterar automatiskt kontokoppling (account linking) på klientsidan utan extra förfrågningar till servern.

Firebase Auth-tokens är JWT (JSON Web Token) med en payload som innehåller UID, utfärdandetid, utgångstid och anpassade claims. Åtkomsttoken lever i 1 timme, refresh-token — obegränsat (men kan återkallas via Admin Console). SDK förnyar automatiskt token vid varje HTTP-förfrågan till Firebase-tjänster. Enligt Google (2026) betjänar Firebase Auth över 500 miljoner autentiseringar per dag.

Prissättning och begränsningar

Firebase Auth är helt gratis i Spark-taxan (gratis) och Blaze-taxan (pay-as-you-go). Den enda begränsningen är 10 000 anonyma autentiseringar per dag i Spark (i Blaze är begränsningen borttagen). E-post/telefon och OAuth-autentiseringar har inga begränsningar. För telefonverifiering erbjuder Spark 10 000 verifieringar per månad, Blaze — betalning per användning ($0,01 per verifiering efter att 10 000 är förbrukade). Detta gör Firebase Auth till en av de mest prisvärda lösningarna på marknaden.

Firebase Auth autentiseringsleverantörer

Firebase Auth stöder 12 autentiseringsleverantörer direkt ur lådan. Varje leverantör är implementerad som en separat identitetstjänst med ett fördefinierat flöde — utvecklaren behöver bara skapa ett Credential-objekt och skicka det till signInWithCredential. Firebase avgör automatiskt om användaren är ny eller befintlig, och vid dubblerad e-post föreslås kontokoppling.

E-post och lösenord

E-post/Lösenord — grundläggande autentiseringsmetod med lagring av lösenordshashar (bcrypt) på Firebases servrar. Registrering, inloggning, lösenordsåterställning via e-post och e-postbekräftelse stöds. Firebase kontrollerar automatiskt lösenordets komplexitet (minst 6 tecken) och kan blockera inloggning efter N misslyckade försök (skydd mot brute-force).

Sociala leverantörer

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — alla OAuth 2.0-leverantörer konfigureras via Firebase-konsolen på 5 minuter. För varje leverantör måste Client ID och Client Secret hämtas från leverantörens egen konsol. Apple Sign In är obligatoriskt för appar i App Store (Apple-krav sedan 2020). Firebase Auth stöder fullt ut Apple Sign In-flödet med JWT-verifiering.

Telefonautentisering

Phone Auth — autentisering via SMS-kod skickad till användarens telefonnummer. Firebase använder Silent APN (iOS) eller SMS Retriever API (Android) för automatisk avläsning av koden utan tangentbordsinmatning. På Android fungerar SMS Retriever API endast på enheter med Google Play Services. För regioner där SMS inte är tillgängligt stöder Firebase reCAPTCHA-verifiering som fallback. Telefonautentisering är avgörande för appar med obligatorisk koppling till nummer — matleverans, taxi, banktjänster.

Integrera Firebase Auth i Android

Ansluta Firebase Auth på Android kräver att beroendet firebase-auth-ktx läggs till i build.gradle och att Firebase App initieras (utförs automatiskt via Google Services plugin). Därefter är FirebaseAuth-objektet tillgängligt via den statiska metoden getInstance() — en singleton för hela appen. Ingen ytterligare konfiguration krävs.

// build.gradle (app-nivå)
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")
}

Registrera användare via e-post

createUserWithEmailAndPassword — den primära metoden för registrering. Den tar emot e-post och lösenord, skapar användaren i Firebase Auth och returnerar ett AuthResult-objekt med UID. Om en användare med denna e-post redan finns returnerar Firebase felet ERROR_EMAIL_ALREADY_IN_USE. Efter lyckad registrering sparar SDK automatiskt token i SharedPreferences och vid nästa start av appen återställs sessionen utan att anropa 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)
        }
    }
}

Inloggning via Google

För Google Sign In används en tvåstegsprocess: inhämtning av ID Token via Credential Manager (Android) eller Google Sign-In SDK, därefter överföring av token till Firebase credential. Firebase verifierar token på sin egen server (kontrollerar signaturen med Googles RSA-nyckel) och skapar eller returnerar den befintliga användaren. Processen kräver ingen lagring av hemligheter på klienten — hela autentiseringen sker genom kryptografisk verifiering av tokens.

Hantera användare och sessioner

Firebase Auth hanterar automatiskt sessionens livscykel. Efter inloggning sparar SDK refresh-token i lokal lagring och vid varje omstart av appen återställs sessionen via signIn silently. Utvecklaren behöver inte implementera tokenlagring, hantering av utgång eller förnyelse — allt görs av Firebase Auth SDK.

Aktuell användare

FirebaseAuth.getInstance().currentUser returnerar ett FirebaseUser-objekt om sessionen är aktiv, eller null om användaren har loggat ut. FirebaseUser innehåller UID, e-post, displayName, photoUrl, phoneNumber, providerData och en lista med claims. Efter profiluppdatering (updateProfile) synkroniseras ändringarna automatiskt med servern. FirebaseUser-objektet cachelagras i minnet och uppdateras vid varje auth-operation.

Anonym autentisering

signInAnonymously — skapar en tillfällig användare utan registrering. Anonyma användare har UID men har ingen e-post, namn eller leverantör. Detta är användbart för appar där innehåll är tillgängligt före registrering (varukorg, favoriter, historik). När användaren bestämmer sig för att registrera sig kopplas det anonyma kontot till ett permanent konto via linkWithCredential. I Spark-taxan finns en gräns på 10 000 anonyma autentiseringar per dag.

Enligt Google (2026) börjar cirka 40 % av användarna att arbeta med appen anonymt, och 25 % av dem kopplar senare det anonyma kontot till ett permanent konto. Detta innebär att anonym autentisering inte förlorar data vid konvertering av användaren till en registrerad användare.

Utloggning och borttagning av konto

Metoden signOut() rensar den lokala sessionen och tar bort den sparade token. Efter anrop av signOut blir currentUser null. Metoden delete() tar bort användarkontot helt från Firebase Auth — alla kopplade leverantörer kopplas bort och åtkomst till Firebase-tjänster blockeras. Borttagning av användare är oåterkallelig och kräver omautentisering (reauthenticate) för att skydda mot obehörig borttagning av konto.

Anpassade claims och rollhantering

Custom Claims är anpassade attribut som Firebase Auth lägger till i användarens JWT-token. Till skillnad från standardprofilfält (e-post, displayName) är claims endast tillgängliga på serversidan — via Admin SDK eller via regler i Firebase Security Rules för Firestore och Realtime Database. Claims är inte direkt synliga för klienten men kan läsas via user.getIdTokenResult().

Typiska användningsscenarier

Roller och åtkomstbehörigheter — det vanligaste tillämpningsscenariot för claims. Admin SDK gör det möjligt att tilldela rollen “admin”, “moderator” eller “premium_user” via en mappning på servern. Dessa claims hamnar automatiskt i token och kan användas i Firestore Security Rules för åtskillnad av åtkomst. Enligt Google (2026) använder 65 % av Firebase-projekten custom claims för dataåtkomsthantering istället för en separat rollserver.

// Admin SDK (Node.js) — tilldela claims till användare
const admin = require("firebase-admin")

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

// Läsa claims på klienten
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Begränsningar för claims

Custom claims har begränsningar: maximalt 1000 byte för hela JSON-claims-objektet per användare, inte mer än 20 nycklar i objektet. Claims är inte avsedda för lagring av dynamisk data — de uppdateras endast via Admin SDK och synkroniseras inte i realtid. Efter uppdatering av claims måste användaren förnya token (getIdTokenResult(true)) eller logga in i appen igen. Claims cachelagras inte på klientsidan — varje ny inloggning får den aktuella token från servern.

Autentiseringssäkerhet

Firebase Auth implementerar flerskiktat kontoskydd: trafikkryptering (TLS 1.3), lösenordshashning (bcrypt, kostnad 10), brute-force-skydd med Adaptive Pricing (automatisk sänkning av svarstid vid misstänkt aktivitet) och integration med reCAPTCHA för webbinloggning. Dessutom inaktiverar Firebase Auth konton vid misstänkt aktivitet — massinloggningar från olika IP-adresser, inloggningsförsök med felaktigt lösenord och misstänkta e-postadresser.

Skyddsmetoder

Account Lockout — automatisk kontospärr efter ett visst antal misslyckade inloggningsförsök. Tröskeln är konfigurerbar i Firebase-konsolen (standard 10 försök). Email Enumeration Protection — skydd mot identifiering av e-postadresser. När den är aktiverad returnerar Firebase samma fel för både befintlig och icke-befintlig e-post. Trusted Domains — begränsning av inloggning till endast användare med e-postdomäner som anges i inställningarna.

Säkerhet för anpassade tokens

Ytterligare anpassad autentisering kan byggas på Custom Tokens — JWT signerade med ett Firebase-tjänstkonto. Klienten skickar den anpassade token till signInWithCustomToken(), Firebase verifierar signaturen och skapar en session. Detta möjliggör integration av Firebase Auth med befintlig serverautentisering (t.ex. OAuth 2.0 från en egen server) utan duplicering av användardatabasen. Token lever i 1 timme, varefter SDK automatiskt förnyar sessionen via en Firebase-refresh-token.