Firebase Auth: ano ito, mga paraan ng pagpapatotoo at mga provider ng pag-login

Ano ang Firebase Auth

Firebase Auth ay isang backend service ng Google para sa pagpapatotoo, na ibinibigay bilang bahagi ng Firebase SDK. Inaako nito ang lahat ng server logic ng pamamahala ng account: pag-iimbak ng mga hash ng password, pagbuo ng mga JWT token, pagproseso ng OAuth 2.0 at OpenID Connect na daloy. Ang developer ay hindi kailangang mag-set up ng sariling auth server, mamahala ng mga refresh token, o magpatupad ng mga verification protocol — lahat ito ay ginagawa ng Firebase.

Arkitektura ng serbisyo

Gumagamit ang Firebase Auth ng federative na arkitektura na may iisang imbakan ng user. Ang bawat user ay tumatanggap ng natatanging identifier (UID) na hindi nakadepende sa provider ng pag-login. Sa pagrehistro sa pamamagitan ng Google at email, isang user ang nilikha na may dalawang naka-link na account (providers). Awtomatikong pinangangasiwaan ng Firebase ang pag-link ng account (account linking) sa gilid ng client nang walang karagdagang kahilingan sa server.

Ang mga token ng Firebase Auth ay JWT (JSON Web Token) na may payload na naglalaman ng UID, oras ng paglabas, oras ng pag-expire, at mga custom na claim. Ang access token ay nabubuhay nang 1 oras, ang refresh token — walang limitasyon (ngunit maaaring bawiin sa pamamagitan ng Admin Console). Awtomatikong nire-renew ng SDK ang token sa bawat HTTP request sa mga serbisyo ng Firebase. Ayon sa Google (2026), ang Firebase Auth ay naglilingkod sa higit sa 500 milyong pagpapatotoo bawat araw.

Mga taripa at limitasyon

Firebase Auth ay ganap na libre sa Spark tariff (libre) at Blaze tariff (pay-as-you-go). Ang tanging limitasyon ay 10 libong anonymous na pagpapatotoo bawat araw sa Spark (sa Blaze ay inalis ang limitasyon). Ang mga pagpapatotoo sa email/telepono at OAuth ay walang limitasyon. Para sa phone verification, ang Spark ay nagbibigay ng 10 libong verification bawat buwan, ang Blaze — bayad ayon sa paggamit ($0.01 bawat verification pagkatapos maubos ang 10 libo). Ginagawa nitong ang Firebase Auth ay isa sa mga pinaka-abot-kayang solusyon sa merkado.

Mga provider ng pagpapatotoo ng Firebase Auth

Firebase Auth ay sumusuporta sa 12 provider ng pagpapatotoo agad-agad. Ang bawat provider ay ipinatupad bilang isang hiwalay na serbisyo ng pagkakakilanlan na may paunang natukoy na daloy — ang developer ay kailangan lamang lumikha ng isang Credential object at ipasa ito sa signInWithCredential. Awtomatikong tinutukoy ng Firebase kung ang user ay bago o umiiral, at sa kaso ng duplicate na email, nag-aalok na i-link ang mga account.

Email at password

Email/Password — pangunahing paraan ng pagpapatotoo na may pag-iimbak ng mga hash ng password (bcrypt) sa mga server ng Firebase. Suportado ang pagrehistro, pag-login, pag-reset ng password sa pamamagitan ng email, at pagkumpirma ng email. Awtomatikong sinusuri ng Firebase ang pagiging kumplikado ng password (minimum na 6 na character) at maaaring harangan ang pag-login pagkatapos ng N nabigong pagtatangka (proteksyon laban sa brute-force).

Mga social provider

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — lahat ng OAuth 2.0 provider ay naka-configure sa pamamagitan ng Firebase console sa loob ng 5 minuto. Para sa bawat provider, kailangang makuha ang Client ID at Client Secret sa console ng provider mismo. Ang Apple Sign In ay sapilitan para sa mga app sa App Store (kinakailangan ng Apple mula noong 2020). Ganap na sinusuportahan ng Firebase Auth ang Apple Sign In flow na may JWT verification.

Phone authentication

Phone Auth — pagpapatotoo sa pamamagitan ng SMS code na ipinadala sa numero ng telepono ng user. Gumagamit ang Firebase ng Silent APN (iOS) o SMS Retriever API (Android) para sa awtomatikong pagbasa ng code nang walang pag-type mula sa keyboard. Sa Android, ang SMS Retriever API ay gumagana lamang sa mga device na may Google Play Services. Para sa mga rehiyon kung saan hindi available ang SMS, sinusuportahan ng Firebase ang reCAPTCHA verification bilang fallback. Ang phone authentication ay kritikal para sa mga app na may obligadong pag-link sa numero — paghahatid ng pagkain, taxi, banking.

Pagsasama ng Firebase Auth sa Android

Pagkonekta ng Firebase Auth sa Android ay nangangailangan ng pagdaragdag ng dependency firebase-auth-ktx sa build.gradle at pagsisimula ng Firebase App (awtomatikong ginagawa sa pamamagitan ng Google Services plugin). Pagkatapos nito, ang FirebaseAuth object ay available sa pamamagitan ng static na pamamaraan ng getInstance() — isang singleton para sa buong app. Walang kinakailangang karagdagang configuration.

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

Pagrehistro ng user sa pamamagitan ng email

createUserWithEmailAndPassword — pangunahing paraan para sa pagrehistro. Tumatanggap ng email at password, lumilikha ng user sa Firebase Auth at nagbabalik ng AuthResult object na may UID. Kung ang user na may ganoong email ay umiiral na, ang Firebase ay nagbabalik ng error na ERROR_EMAIL_ALREADY_IN_USE. Pagkatapos ng matagumpay na pagrehistro, awtomatikong sine-save ng SDK ang token sa SharedPreferences at sa susunod na paglunsad ng app ay ibinabalik ang session nang hindi tumatawag ng 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)
        }
    }
}

Pag-login sa pamamagitan ng Google

Para sa Google Sign In ginagamit ang dalawang-hakbang na proseso: pagkuha ng ID Token sa pamamagitan ng Credential Manager (Android) o Google Sign-In SDK, pagkatapos ay pagpapasa ng token sa Firebase credential. Bini-verify ng Firebase ang token sa sarili nitong server (sinusuri ang lagda gamit ang RSA key ng Google) at lumilikha o nagbabalik ng umiiral na user. Ang proseso ay hindi nangangailangan ng pag-iimbak ng secret sa client — ang buong pagpapatotoo ay ginagawa sa pamamagitan ng cryptographic verification ng mga token.

Pamamahala ng mga user at session

Firebase Auth ay awtomatikong namamahala sa lifecycle ng session. Pagkatapos mag-login, sine-save ng SDK ang refresh token sa lokal na imbakan, at sa bawat pag-restart ng app ay ibinabalik ang session sa pamamagitan ng signIn silently. Ang developer ay hindi kailangang magpatupad ng pag-iimbak ng token, paghawak ng pag-expire nito, o pag-renew — lahat ay ginagawa ng Firebase Auth SDK.

Kasalukuyang user

FirebaseAuth.getInstance().currentUser ay nagbabalik ng FirebaseUser object kung ang session ay aktibo, o null kung ang user ay naka-logout. Ang FirebaseUser ay naglalaman ng UID, email, displayName, photoUrl, phoneNumber, providerData at listahan ng mga claim. Pagkatapos ng pag-update ng profile (updateProfile), ang mga pagbabago ay awtomatikong nai-sync sa server. Ang FirebaseUser object ay naka-cache sa memory at na-update sa anumang auth operation.

Anonymous authentication

signInAnonymously — lumilikha ng pansamantalang user nang walang pagrehistro. Ang mga anonymous na user ay may UID, ngunit walang email, pangalan, o provider. Ito ay kapaki-pakinabang para sa mga app kung saan ang nilalaman ay available bago ang pagrehistro (cart, favorites, history). Kapag nagpasya ang user na magrehistro, ang anonymous na account ay naka-link sa permanenteng account sa pamamagitan ng linkWithCredential. Sa Spark tariff, may limitasyon na 10 libong anonymous authentication bawat araw.

Ayon sa Google (2026), humigit-kumulang 40% ng mga user ang nagsisimulang magtrabaho sa app nang anonymous, at 25% sa kanila ay nagli-link ng anonymous na account sa isang permanenteng account. Nangangahulugan ito na ang anonymous authentication ay hindi nawawalan ng data sa conversion ng user sa rehistradong user.

Pag-logout at pagtanggal ng account

Ang pamamaraang signOut() ay naglilinis ng lokal na session at nagtatanggal ng naka-save na token. Pagkatapos tawagan ang signOut, ang currentUser ay nagiging null. Ang pamamaraang delete() ay ganap na nagtatanggal ng user account mula sa Firebase Auth — lahat ng naka-link na provider ay nadidiskonekta at ang access sa mga serbisyo ng Firebase ay naharang. Ang pagtanggal ng user ay hindi na mababawi at nangangailangan ng muling pagpapatotoo (reauthenticate) para sa proteksyon laban sa hindi awtorisadong pagtanggal ng account.

Mga custom na claim at pamamahala ng tungkulin

Custom Claims ay mga custom na attribute na idinadagdag ng Firebase Auth sa JWT token ng user. Hindi tulad ng mga standard na field ng profile (email, displayName), ang mga claim ay available lamang sa gilid ng server — sa pamamagitan ng Admin SDK o sa pamamagitan ng mga patakaran sa Firebase Security Rules para sa Firestore at Realtime Database. Ang mga claim ay hindi direktang nakikita ng client, ngunit maaaring basahin sa pamamagitan ng user.getIdTokenResult().

Mga tipikal na sitwasyon ng paggamit

Mga tungkulin at pahintulot sa pag-access — ang pinakakaraniwang sitwasyon ng paglalapat ng mga claim. Pinapayagan ng Admin SDK ang pagtatalaga ng tungkuling “admin”, “moderator” o “premium_user” sa pamamagitan ng mapping sa server. Ang mga claim na ito ay awtomatikong pumapasok sa token at maaaring gamitin sa Firestore Security Rules para sa paghihiwalay ng access. Ayon sa Google (2026), 65% ng mga proyekto sa Firebase ay gumagamit ng custom claims para sa pamamahala ng access sa data sa halip na isang hiwalay na server ng tungkulin.

// Admin SDK (Node.js) — pagtatalaga ng mga claim sa user
const admin = require("firebase-admin")

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

// Pagbasa ng mga claim sa gilid ng client
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Mga limitasyon ng claim

Custom claims ay may mga limitasyon: maximum na 1000 bytes para sa buong JSON claims object bawat user, hindi hihigit sa 20 key sa object. Ang mga claim ay hindi inilaan para sa pag-iimbak ng dynamic na data — sila ay na-update lamang sa pamamagitan ng Admin SDK at hindi nag-sync sa real-time. Pagkatapos ng pag-update ng mga claim, ang user ay dapat mag-renew ng token (getIdTokenResult(true)) o mag-login muli sa app. Ang mga claim ay hindi naka-cache sa gilid ng client — bawat bagong login ay tumatanggap ng kasalukuyang token mula sa server.

Seguridad ng pagpapatotoo

Firebase Auth ay nagpapatupad ng multi-layer na proteksyon ng account: encryption ng trapiko (TLS 1.3), hashing ng password (bcrypt, cost 10), proteksyon laban sa brute-force gamit ang Adaptive Pricing (awtomatikong pagbagal ng tugon sa kahina-hinalang aktibidad) at integration sa reCAPTCHA para sa web login. Bilang karagdagan, ang Firebase Auth ay nagdi-deactivate ng mga account sa kahina-hinalang aktibidad — maramihang pag-login mula sa iba't ibang IP, pagtatangkang mag-login gamit ang maling password, at kahina-hinalang email address.

Mga paraan ng proteksyon

Account Lockout — awtomatikong pag-block ng account pagkatapos ng isang tiyak na bilang ng mga nabigong pagtatangka sa pag-login. Ang threshold ay nako-configure sa Firebase console (default na 10 pagtatangka). Email Enumeration Protection — proteksyon laban sa paghahanap ng mga email address. Kapag naka-enable, ang Firebase ay nagbabalik ng parehong error para sa parehong umiiral at hindi umiiral na email. Trusted Domains — paglilimita ng pag-login sa mga user lamang na may mga email domain na tinukoy sa mga setting.

Seguridad ng mga custom na token

Ang karagdagang custom authentication ay maaaring itayo sa Custom Tokens — JWT na pinirmahan ng Firebase service account. Ipinapasa ng client ang custom na token sa signInWithCustomToken(), bini-verify ng Firebase ang pirma at lumilikha ng session. Pinapayagan nito ang integration ng Firebase Auth sa umiiral na server authentication (hal., OAuth 2.0 ng sariling server) nang hindi dinu-duplicate ang database ng user. Ang token ay nabubuhay nang 1 oras, pagkatapos ay awtomatikong nire-renew ng SDK ang session sa pamamagitan ng Firebase refresh token.