Firebase Auth: یہ کیا ہے، تصدیق کے طریقے اور سائن ان فراہم کنندگان

Firebase Auth کیا ہے

Firebase Auth Firebase SDK کے حصے کے طور پر فراہم کردہ Google کی بیک اینڈ تصدیقی سروس ہے۔ یہ سرور سائیڈ اکاؤنٹ مینجمنٹ کی تمام منطق سنبھالتی ہے: پاس ورڈ ہیشز کو ذخیرہ کرنا، JWT ٹوکن بنانا، اور OAuth 2.0 اور OpenID Connect فلو کو پروسیس کرنا۔ ڈیولپرز کو اپنا تصدیقی سرور تعینات کرنے، ریفریش ٹوکن کا نظم کرنے یا تصدیقی پروٹوکول لاگو کرنے کی ضرورت نہیں ہے — Firebase سب کچھ کرتا ہے۔

سروس کا فن تعمیر

Firebase Auth ایک متحد صارف ذخیرہ کے ساتھ وفاقی فن تعمیر استعمال کرتا ہے۔ ہر صارف کو ایک منفرد شناخت کنندہ (UID) ملتا ہے جو سائن ان فراہم کنندہ پر منحصر نہیں ہوتا۔ Google اور ای میل کے ذریعے رجسٹر کرتے وقت، دو منسلک اکاؤنٹس (فراہم کنندگان) کے ساتھ ایک صارف بنایا جاتا ہے۔ Firebase اضافی سرور کی درخواستوں کے بغیر کلائنٹ سائیڈ پر خود بخود اکاؤنٹ لنکنگ سنبھالتا ہے۔

Firebase Auth ٹوکن JWT (JSON Web Token) ہیں جن میں UID، جاری کرنے کا وقت، میعاد ختم ہونے کا وقت اور کسٹم claims پر مشتمل پے لوڈ ہوتا ہے۔ رسائی ٹوکن 1 گھنٹے تک رہتے ہیں، ریفریش ٹوکن لامحدود ہیں (لیکن ایڈمن کنسول کے ذریعے منسوخ کیے جا سکتے ہیں)۔ SDK Firebase سروسز کو ہر HTTP درخواست پر خود بخود ٹوکن ریفریش کرتا ہے۔ Google (2026) کے مطابق، Firebase Auth روزانہ 500 ملین سے زیادہ تصدیقات کا نظم کرتا ہے۔

قیمت اور حدود

Firebase Auth Spark پلان (مفت) اور Blaze پلان (ادائیگی جیسے استعمال) پر مکمل طور پر مفت ہے۔ واحد حد Spark پر روزانہ 10 ہزار گمنام تصدیقات ہے (Blaze پر لامحدود)۔ ای میل/فون اور OAuth تصدیقات کی کوئی حد نہیں ہے۔ فون کی تصدیق کے لیے، Spark ماہانہ 10 ہزار تصدیقات فراہم کرتا ہے، جبکہ Blaze استعمال کے مطابق چارج کرتا ہے (پہلے 10 ہزار کے بعد ہر تصدیق $0.01)۔ یہ Firebase Auth کو مارکیٹ کے سب سے سستی حل میں سے ایک بناتا ہے۔

Firebase Auth تصدیقی فراہم کنندگان

Firebase Auth باکس سے باہر 12 تصدیقی فراہم کنندگان کو سپورٹ کرتا ہے۔ ہر فراہم کنندہ ایک پہلے سے طے شدہ فلو کے ساتھ ایک علیحدہ شناختی سروس کے طور پر لاگو کیا جاتا ہے — ڈیولپر کو صرف ایک Credential آبجیکٹ بنانا اور اسے signInWithCredential میں دینا ہوتا ہے۔ Firebase خود بخود طے کرتا ہے کہ صارف نیا ہے یا موجودہ، اور ای میل کی نقل کی صورت میں، اکاؤنٹس کو منسلک کرنے کی پیشکش کرتا ہے۔

ای میل اور پاس ورڈ

Email/Password Firebase سرورز پر ذخیرہ شدہ پاس ورڈ ہیشز (bcrypt) کے ساتھ بنیادی تصدیقی طریقہ ہے۔ یہ رجسٹریشن، سائن ان، ای میل کے ذریعے پاس ورڈ ری سیٹ اور ای میل کی تصدیق کو سپورٹ کرتا ہے۔ Firebase خود بخود پاس ورڈ کی مضبوطی چیک کرتا ہے (کم از کم 6 حروف) اور N ناکام کوششوں کے بعد سائن ان کو مسدود کر سکتا ہے (بروٹ فورس تحفظ)۔

سماجی فراہم کنندگان

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — تمام OAuth 2.0 فراہم کنندگان کو Firebase کنسول کے ذریعے 5 منٹ میں ترتیب دیا جا سکتا ہے۔ ہر فراہم کنندہ کے لیے، آپ کو فراہم کنندہ کے اپنے کنسول سے Client ID اور Client Secret حاصل کرنے کی ضرورت ہے۔ Apple Sign In App Store ایپلیکیشنز کے لیے لازمی ہے (2020 سے Apple کی ضرورت)۔ Firebase Auth JWT تصدیق کے ساتھ Apple Sign In فلو کو مکمل طور پر سپورٹ کرتا ہے۔

فون کی تصدیق

Phone Auth صارف کے فون نمبر پر بھیجے گئے SMS کوڈ کے ذریعے تصدیق ہے۔ Firebase کی بورڈ ان پٹ کے بغیر کوڈ خود بخود پڑھنے کے لیے Silent APN (iOS) یا SMS Retriever API (Android) استعمال کرتا ہے۔ Android پر، SMS Retriever API صرف Google Play Services والے آلات پر کام کرتا ہے۔ ان خطوں کے لیے جہاں SMS دستیاب نہیں ہے، Firebase فال بیک کے طور پر reCAPTCHA تصدیق کو سپورٹ کرتا ہے۔ فون کی تصدیق ان ایپس کے لیے اہم ہے جنہیں فون نمبر بائنڈنگ کی ضرورت ہوتی ہے — فوڈ ڈیلیوری، رائیڈ ہیلنگ، بینکنگ۔

Android میں Firebase Auth کا انضمام

Android میں Firebase Auth شامل کرنا build.gradle میں firebase-auth-ktx انحصار شامل کرنے اور Firebase App کو ابتدائی شکل دینے کی ضرورت ہے (Google Services پلگ ان کے ذریعے خود بخود ہوتا ہے)۔ اس کے بعد، FirebaseAuth آبجیکٹ جامد طریقہ getInstance() کے ذریعے دستیاب ہے — پوری ایپ کے لیے ایک سنگلٹن۔ کسی اضافی ترتیب کی ضرورت نہیں ہے۔

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

ای میل کے ذریعے صارف رجسٹریشن

createUserWithEmailAndPassword رجسٹریشن کا بنیادی طریقہ ہے۔ یہ ایک ای میل اور پاس ورڈ لیتا ہے، Firebase Auth میں ایک صارف بناتا ہے اور UID کے ساتھ AuthResult آبجیکٹ لوٹاتا ہے۔ اگر اس ای میل والا صارف پہلے سے موجود ہے، تو Firebase ERROR_EMAIL_ALREADY_IN_USE کی خرابی لوٹاتا ہے۔ کامیاب رجسٹریشن کے بعد، SDK خود بخود SharedPreferences میں ٹوکن محفوظ کرتا ہے اور اگلی ایپ لانچ پر 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)
        }
    }
}

Google سائن ان

Google Sign In کے لیے دو مرحلوں کا عمل استعمال کیا جاتا ہے: Credential Manager (Android) یا Google Sign-In SDK کے ذریعے ID Token حاصل کرنا، پھر ٹوکن کو Firebase اسناد میں دینا۔ Firebase اپنے سرور پر ٹوکن کی تصدیق کرتا ہے (Google کی RSA کلید سے دستخط چیک کرتا ہے) اور موجودہ صارف بناتا یا لوٹاتا ہے۔ اس عمل میں کلائنٹ پر کوئی راز محفوظ کرنے کی ضرورت نہیں ہے — تمام تصدیق خفیہ نگاری کی تصدیق کے ذریعے کی جاتی ہے۔

صارف کا نظم اور سیشنز

Firebase Auth خود بخود سیشن لائف سائیکل کا نظم کرتا ہے۔ سائن ان کے بعد، SDK ریفریش ٹوکن کو مقامی اسٹوریج میں محفوظ کرتا ہے، اور ہر ایپ ری اسٹارٹ پر، خاموش سائن ان کے ذریعے سیشن بحال کرتا ہے۔ ڈیولپرز کو ٹوکن اسٹوریج، میعاد ختم ہونے کا نظم یا ریفریش لاگو کرنے کی ضرورت نہیں ہے — Firebase Auth SDK سب کچھ کرتا ہے۔

موجودہ صارف

FirebaseAuth.getInstance().currentUser اگر سیشن فعال ہے تو FirebaseUser آبجیکٹ لوٹاتا ہے، یا اگر صارف نے سائن آؤٹ کیا ہے تو null لوٹاتا ہے۔ FirebaseUser میں UID، ای میل، displayName، photoUrl، phoneNumber، providerData اور claims کی فہرست ہوتی ہے۔ پروفائل اپ ڈیٹس (updateProfile) کے بعد، تبدیلیاں خود بخود سرور کے ساتھ مطابقت پذیر ہو جاتی ہیں۔ FirebaseUser آبجیکٹ میموری میں کیش ہوتا ہے اور کسی بھی تصدیقی کارروائی پر اپ ڈیٹ ہوتا ہے۔

گمنام تصدیق

signInAnonymously بغیر رجسٹریشن کے ایک عارضی صارف بناتا ہے۔ گمنام صارفین کے پاس UID ہوتا ہے لیکن کوئی ای میل، نام یا فراہم کنندہ نہیں ہوتا۔ یہ ان ایپس کے لیے مفید ہے جہاں رجسٹریشن سے پہلے مواد دستیاب ہوتا ہے (کارٹ، پسندیدہ، تاریخ)۔ جب صارف رجسٹر کرنے کا فیصلہ کرتا ہے، تو گمنام اکاؤنٹ linkWithCredential کے ذریعے مستقل اکاؤنٹ سے منسلک ہو جاتا ہے۔ Spark پلان پر، روزانہ 10 ہزار گمنام تصدیقات کی حد ہے۔

Google (2026) کے مطابق، تقریباً 40% صارفین گمنام طور پر ایپ استعمال کرنا شروع کرتے ہیں، اور ان میں سے 25% بعد میں اپنے گمنام اکاؤنٹ کو مستقل اکاؤنٹ سے منسلک کرتے ہیں۔ اس کا مطلب ہے کہ گمنام تصدیق صارف کو رجسٹرڈ میں تبدیل کرنے پر ڈیٹا نہیں کھوتی۔

سائن آؤٹ اور اکاؤنٹ حذف کرنا

signOut() طریقہ مقامی سیشن صاف کرتا ہے اور محفوظ کردہ ٹوکن ہٹا دیتا ہے۔ signOut کو کال کرنے کے بعد، currentUser null ہو جاتا ہے۔ delete() طریقہ صارف اکاؤنٹ کو Firebase Auth سے مکمل طور پر ہٹا دیتا ہے — تمام منسلک فراہم کنندگان منقطع ہو جاتے ہیں اور Firebase سروسز تک رسائی مسدود ہو جاتی ہے۔ صارف کو حذف کرنا ناقابل واپسی ہے اور غیر مجاز اکاؤنٹ حذف کرنے سے بچانے کے لیے دوبارہ تصدیق کی ضرورت ہوتی ہے۔

کسٹم Claims اور کردار کا نظم

Custom Claims وہ کسٹم صفات ہیں جو Firebase Auth صارف کے JWT ٹوکن میں شامل کرتا ہے۔ معیاری پروفائل فیلڈز (ای میل، displayName) کے برعکس، claims صرف سرور سائیڈ پر دستیاب ہیں — Admin SDK کے ذریعے یا Firestore اور Realtime Database کے لیے Firebase Security Rules میں قواعد کے ذریعے۔ Claims کلائنٹ کو براہ راست نظر نہیں آتے لیکن user.getIdTokenResult() کے ذریعے پڑھے جا سکتے ہیں۔

عام استعمال کے معاملات

کردار اور رسائی کے حقوق claims کے سب سے عام استعمال کے معاملات ہیں۔ Admin SDK سرور پر ایک نقشے کے ذریعے “admin”، “moderator” یا “premium_user” کردار تفویض کرنے کی اجازت دیتا ہے۔ یہ claims خود بخود ٹوکن میں شامل ہو جاتے ہیں اور رسائی کے کنٹرول کے لیے Firestore Security Rules میں استعمال کیے جا سکتے ہیں۔ Google (2026) کے مطابق، 65% Firebase منصوبے علیحدہ کردار سرور کے بجائے ڈیٹا تک رسائی کے نظم کے لیے کسٹم claims استعمال کرتے ہیں۔

// Admin SDK (Node.js) — صارف کو claims تفویض کرنا
const admin = require("firebase-admin")

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

// کلائنٹ پر claims پڑھنا
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Claims کی حدود

کسٹم claims کی حدود ہیں: فی صارف پورے JSON claims آبجیکٹ کے لیے زیادہ سے زیادہ 1000 بائٹس، آبجیکٹ میں 20 سے زیادہ چابیاں نہیں۔ Claims متحرک ڈیٹا ذخیرہ کرنے کے لیے ڈیزائن نہیں کیے گئے ہیں — وہ صرف Admin SDK کے ذریعے اپ ڈیٹ ہوتے ہیں اور حقیقی وقت میں مطابقت پذیر نہیں ہوتے۔ Claims کو اپ ڈیٹ کرنے کے بعد، صارف کو ٹوکن ریفریش کرنا ہوگا (getIdTokenResult(true)) یا ایپ میں دوبارہ لاگ ان کرنا ہوگا۔ Claims کلائنٹ پر کیش نہیں ہوتے — ہر نیا لاگ ان سرور سے تازہ ترین ٹوکن حاصل کرتا ہے۔

تصدیق کی حفاظت

Firebase Auth کثیر سطحی اکاؤنٹ تحفظ لاگو کرتا ہے: ٹریفک خفیہ کاری (TLS 1.3)، پاس ورڈ ہیشنگ (bcrypt، لاگت 10)، Adaptive Pricing کے ساتھ بروٹ فورس تحفظ (مشکوک سرگرمی پر خودکار ردعمل سست کرنا)، اور ویب سائن ان کے لیے reCAPTCHA انضمام۔ مزید برآں، Firebase Auth مشکوک سرگرمی پر اکاؤنٹس کو غیر فعال کر دیتا ہے — مختلف IPs سے اجتماعی لاگ ان، غلط پاس ورڈ کی کوششیں اور مشکوک ای میل پتے۔

تحفظ کے طریقے

Account Lockout — ناکام سائن ان کوششوں کی ایک مخصوص تعداد کے بعد خودکار اکاؤنٹ لاک آؤٹ۔ حد Firebase کنسول میں ترتیب دی جا سکتی ہے (پہلے سے طے شدہ 10 کوششیں)۔ Email Enumeration Protection — ای میل پتوں کی گنتی سے تحفظ۔ فعال ہونے پر، Firebase موجودہ اور غیر موجود دونوں ای میل کے لیے ایک ہی خرابی لوٹاتا ہے۔ Trusted Domains — سائن ان کو صرف ترتیبات میں مخصوص کردہ ای میل ڈومین والے صارفین تک محدود کرنا۔

کسٹم ٹوکن کی حفاظت

اضافی کسٹم تصدیق Custom Tokens — Firebase سروس اکاؤنٹ کے ذریعے دستخط کردہ JWT استعمال کرکے بنائی جا سکتی ہے۔ کلائنٹ کسٹم ٹوکن signInWithCustomToken() میں دیتا ہے، Firebase دستخط کی تصدیق کرتا ہے اور ایک سیشن بناتا ہے۔ یہ صارف ڈیٹا بیس کو نقل کیے بغیر Firebase Auth کو موجودہ سرور سائیڈ تصدیق (مثال کے طور پر، آپ کا اپنا OAuth 2.0 سرور) کے ساتھ ضم کرنے کی اجازت دیتا ہے۔ ٹوکن 1 گھنٹے تک رہتا ہے، جس کے بعد SDK Firebase ریفریش ٹوکن کے ذریعے خود بخود سیشن ریفریش کرتا ہے۔