Google Sign-In: یہ کیا ہے، Google لاگ ان اور OAuth 2.0 SDK

Google Sign-In کیا ہے؟

Google Sign-In ایک سنگل سائن آن (SSO) سروس ہے جو Google کی طرف سے تیسرے فریق کی ایپلیکیشنز میں صارف کی تصدیق کے لیے فراہم کی گئی ہے۔ SDK ڈویلپرز کو اپنا خود کا رجسٹریشن سسٹم بنائے بغیر Google اکاؤنٹ کے ذریعے لاگ ان کو ضم کرنے کی اجازت دیتا ہے۔ یہ ٹیکنالوجی OAuth 2.0 پروٹوکول اور OpenID Connect پر مبنی ہے، جو صارف کی شناخت کی معلومات فراہم کرتی ہے: نام، ای میل، اوتار اور منفرد شناخت کنندہ۔

روایتی ای میل اور پاس ورڈ کی تصدیق کے برعکس، Google Sign-In پاس ورڈ یاد رکھنے اور رجسٹریشن کے عمل سے گزرنے کی ضرورت کو ختم کرتا ہے۔ صارف ڈیوائس پر Google اکاؤنٹ منتخب کرتا ہے، اجازتوں کی تصدیق کرتا ہے، اور ایپ کو رسائی کا ٹوکن مل جاتا ہے۔ Google Identity Platform (2025) کے مطابق، Google Sign-In والی ایپس ای میل/پاس ورڈ فارم کے مقابلے میں 52% زیادہ کامیاب رجسٹریشن دکھاتی ہیں۔

Google Sign-In تین استعمال کے منظرناموں کو سپورٹ کرتا ہے: صارف کی تصدیق (ID Token حاصل کرنا)، Google API تک رسائی کے لیے اجازت دہی (Access Token حاصل کرنا)، اور پہلے سے مجاز صارفین کے لیے ہموار تصدیق (Silent Sign-In)۔ ہر منظرنامے کے لیے مختلف دائرہ کار (scopes) کی ضرورت ہوتی ہے اور مختلف اقسام کے ٹوکن واپس کرتا ہے۔

Google Sign-In میں OAuth 2.0 کیسے کام کرتا ہے

OAuth 2.0 ایک اجازت دہی کا پروٹوکول ہے جو ایپ کو صارف کی اسناد ظاہر کیے بغیر صارف کے وسائل تک محدود رسائی حاصل کرنے کی اجازت دیتا ہے۔ Google Sign-In کے تناظر میں، پروٹوکول اس طرح کام کرتا ہے: ایپ Google کے ذریعے صارف سے اجازت طلب کرتی ہے، ایک عارضی اجازت کوڈ حاصل کرتی ہے، اسے رسائی کے ٹوکن سے تبدیل کرتی ہے، اور ان ٹوکن کو Google API کال کرنے کے لیے استعمال کرتی ہے۔

OAuth 2.0 کا پچھلے پروٹوکول سے اہم فرق وسائل کے مالک (صارف)، کلائنٹ (ایپ)، اجازت دہی سرور (Google) اور وسائل کے سرور (Google API) کے درمیان کرداروں کی علیحدگی ہے۔ ایپ کبھی بھی صارف کا پاس ورڈ حاصل نہیں کرتی — صرف ایک ٹوکن جسے منسوخ کیا جا سکتا ہے۔ Google Identity Platform OAuth 2.0 کے اوپر OpenID Connect تصریح استعمال کرتا ہے، JWT فارمیٹ میں ایک معیاری ID Token شامل کرتا ہے۔

ID Token بمقابلہ Access Token: فرق

// Credential Manager کے ذریعے ID Token حاصل کرنے کی مثال
val googleIdOption = GoogleIdCredentialOption.Builder()
    .setServerClientId(serverClientId)
    .build()

val credentialManager = CredentialManager.create(this)
val request = GetCredentialRequest.Builder()
    .addCredentialOption(googleIdOption)
    .build()

credentialManager.getCredential(request)
    .addOnSuccessListener { result ->
        val credential = result.credential as GoogleIdCredential
        Log.d("SignIn", credential.idToken)
    }

ID Token (JWT) تین حصوں پر مشتمل ہوتا ہے: دستخط الگورتھم کے ساتھ ہیڈر، صارف کے ڈیٹا (sub، email، name، picture) کے ساتھ پے لوڈ، اور تصدیق کے لیے دستخط۔ ایپ کا سرور سائیڈ حصہ Google کی عوامی چابیاں استعمال کرکے ID Token کے دستخط کی تصدیق کرتا ہے اور صارف کی شناخت کنندہ نکالتا ہے۔ یہ نقطہ نظر اس بات کی ضمانت دیتا ہے کہ اگر کلائنٹ ایپ سے سمجھوتہ بھی ہو جائے تو حملہ آور Google کی نجی کلید تک رسائی کے بغیر ٹوکن جعلی نہیں بنا سکتا۔

Credential Manager: Android پر لاگ ان کا نیا طریقہ

Credential Manager 2023 میں متعارف کرایا گیا ایک جدید Android API ہے جو تمام تصدیقی طریقوں (Google Sign-In، پاس ورڈ لاگ ان، Passkeys) کو ایک ہی یوزر انٹرفیس میں یکجا کرتا ہے۔ پرانے GoogleSignInClient کے برعکس، Credential Manager کو لاگ ان کے لیے WebView کی ضرورت نہیں — یہ ایک مقامی Bottom Sheet استعمال کرتا ہے، جو تصدیق کو تیز کرتا ہے اور صارف کے تجربے کو بہتر بناتا ہے۔

Credential Manager کا بنیادی فائدہ تمام اسناد کی اقسام کے لیے یکساں یوزر تجربہ ہے۔ صارف ایک ڈائیلاگ دیکھتا ہے جہاں وہ انتخاب کر سکتا ہے: Google سے سائن ان کریں، Passkey استعمال کریں، یا پاس ورڈ درج کریں۔ ڈویلپر کو مختلف تصدیقی بہاؤ کو منظم کرنے کی ضرورت نہیں — Credential Manager Google Sign-In، Smart Lock اور Passkeys کے ساتھ تعامل کو خلاصہ کرتا ہے۔ Google Android 14+ کے لیے Google Sign-In انضمام کے بنیادی طریقے کے طور پر Credential Manager کی سفارش کرتا ہے۔

GoogleSignInClient سے Credential Manager میں منتقلی

منتقلی GoogleSignInClient سے Credential Manager میں کلائنٹ سائیڈ منطق میں تبدیلی کی ضرورت ہے: GoogleSignInOptions کی بجائے GoogleIdCredentialOption استعمال کریں، اور GoogleSignIn.getSignedInAccountFromIntent کی بجائے GetCredentialResponse کے ذریعے نتیجہ پر کارروائی کریں۔ سرور سائیڈ حصے میں تبدیلی کی ضرورت نہیں کیونکہ ID Token وہی JWT فارمیٹ برقرار رکھتا ہے۔ Google I/O 2024 کے مطابق، Google Play پر تقریباً 40% ایپس پہلے ہی Credential Manager میں منتقل ہو چکی ہیں۔

Android پروجیکٹ میں Google Sign-In ترتیب دینا

Google Sign-In کو Android ایپ میں ضم کرنا Google Cloud Console میں پروجیکٹ کو ترتیب دینے سے شروع ہوتا ہے۔ پہلا قدم Android کے لیے OAuth 2.0 Client ID بنانا ہے: ایپ کا پیکیج نام اور SHA-1 سرٹیفکیٹ فنگر پرنٹ بتائیں۔ Google اس ڈیٹا کو اس بات کی تصدیق کرنے کے لیے استعمال کرتا ہے کہ تصدیق کی درخواست آپ کی ایپ سے آرہی ہے نہ کہ جعلی کلائنٹ سے۔

Google Cloud Console میں کلائنٹ بنانے کے بعد، ڈویلپر build.gradle میں Credential Manager کا انحصار شامل کرتا ہے اور serverClientId کے ساتھ GoogleIdCredentialOption ترتیب دیتا ہے۔ اہم: serverClientId اسی Google Cloud پروجیکٹ کی ویب ایپلیکیشن کا Client ID ہے، جسے سرور سائیڈ ID Token کی تصدیق کے لیے استعمال کرتا ہے۔ کلائنٹ ایپ ٹوکن کی تصدیق نہیں کرتی — یہ صرف اسے وصول کرتی ہے اور سرور کو بھیجتی ہے۔

// build.gradle (app) dependencies
implementation("androidx.credentials:credentials:1.5.0")
implementation("androidx.credentials:credentials-play-services-auth:1.5.0")
implementation("com.google.android.libraries.identity.googleid:googleid:1.1.0")

// Credential Manager کے ذریعے Google Sign-In کی درخواست
suspend fun requestGoogleSignIn(context: Context): String? {
    val credentialManager = CredentialManager.create(context)
    val googleIdOption = GoogleIdCredentialOption.Builder()
        .setServerClientId(BuildConfig.SERVER_CLIENT_ID)
        .setAutoSelectEnabled(true)
        .build()

    val result = credentialManager.getCredential(
        context as Activity,
        GetCredentialRequest.Builder()
            .addCredentialOption(googleIdOption)
            .build()
    )
    return (result.credential as GoogleIdCredential).idToken
}

کلائنٹ پر ID Token حاصل کرنے کے بعد، ایپ اسے اپنے سرور پر بھیجتی ہے جہاں تصدیق کی جاتی ہے۔ سرور Google کی عوامی چابیاں (https://www.googleapis.com/oauth2/v3/certs پر دستیاب)، ٹوکن کی میعاد ختم ہونے کا وقت (exp) اور aud فیلڈ کی قدر استعمال کرکے JWT دستخط کی تصدیق کرتا ہے — اسے serverClientId سے ملنا چاہیے۔ تصدیق کے بعد، سرور اپنا سیشن بناتا ہے، مثلاً اندرونی JWT یا Session Token جاری کرتا ہے۔

iOS پر Google Sign-In: سیٹ اپ اور خصوصیات

iOS پر Google Sign-In کا انضمام GoogleSignIn-iOS SDK کے ذریعے کیا جاتا ہے، جو CocoaPods یا Swift Package Manager کے ذریعے دستیاب ہے۔ سیٹ اپ کے عمل میں Google Cloud Console میں iOS کے لیے Client ID بنانا (Bundle Identifier بتاتے ہوئے)، کال بیک کے لیے URL Scheme شامل کرنا، اور تصدیق کے بعد Google کی طرف سے لوٹائے گئے URL کو سنبھالنے کے لیے AppDelegate ترتیب دینا شامل ہے۔

Google Sign-In کے iOS ورژن کا Android سے ایک اہم فرق URL Scheme اور Info.plist کو ترتیب دینے کی ضرورت ہے۔ GoogleSDK کال بیک کے لیے Universal Links استعمال کرتا ہے، لیکن فال بیک کے لیے `com.googleusercontent.apps.[CLIENT_ID]` فارم کے URL Scheme کی ضرورت ہے۔ ایپ لانچ کے درمیان ریفریش ٹوکن کو محفوظ کرنے کے لیے Keychain Sharing ترتیب کی بھی ضرورت ہے۔ Google Identity دستاویزات کے مطابق، iOS SDK iOS 15 اور اس سے اوپر کو سپورٹ کرتا ہے۔

// iOS پر Google Sign-In ترتیب دینا
import GoogleSignIn

class SignInManager: ObservableObject {
    func signIn(presenting viewController: UIViewController) {
        GIDSignIn.sharedInstance.signIn(
            withPresenting: viewController
        ) { signInResult, error in
            guard let result = signInResult else {
                print("Sign in failed: \(error)")
                return
            }
            let idToken = result.user.idToken.tokenString
            // ID Token سرور کو بھیجنا
            sendTokenToBackend(idToken)
        }
    }
}

iOS پر، Google Sign-In ان صارفین کے لیے Silent Sign-In کو سپورٹ کرتا ہے جنہوں نے پہلے اجازت دی ہے۔ restorePreviousSignIn طریقہ خود بخود سیشن بحال کرتا ہے اگر ریفریش ٹوکن Keychain میں محفوظ ہے۔ یہ خاص طور پر ان ایپس کے لیے اہم ہے جہاں صارف کو ہر لانچ پر دوبارہ لاگ ان نہیں کرنا چاہیے۔ Google کے مطابق، فعال Google سیشن والے آلات پر Silent Sign-In 85% معاملات میں کامیاب ہوتا ہے۔

ٹوکن کا انتظام اور سیکیورٹی

Google Sign-In کی سیکیورٹی تین سطحوں پر بنائی گئی ہے: کلائنٹ کی تصدیق (SHA-1 ایپ دستخط)، ٹرانسپورٹ انکرپشن (HTTPS/TLS) اور کرپٹوگرافک JWT دستخط۔ Google سے موصول ہونے والا ID Token RS256 الگورتھم (SHA-256 کے ساتھ RSA) کا استعمال کرکے دستخط کیا جاتا ہے۔ ایپ کے سرور سائیڈ حصے کو ٹوکن کے دستخط، میعاد ختم ہونے اور جاری کنندہ (iss) — صرف accounts.google.com — کی تصدیق کرنی چاہیے۔

Access Token ایک عارضی ٹوکن ہے (1 گھنٹہ زندہ رہتا ہے) جو Google API (Google Drive، Google Calendar، YouTube، وغیرہ) تک رسائی فراہم کرتا ہے۔ ID Token کے برعکس، Access Token میں صارف کی معلومات نہیں ہوتی — یہ ایک غیر شفاف سٹرنگ ہے جسے Google API سرور درخواست کی اجازت دہی کے لیے استعمال کرتا ہے۔ Refresh Token ایک طویل عرصے تک زندہ رہنے والا ٹوکن ہے جو صارف کے دوبارہ لاگ ان کیے بغیر نئے Access Token حاصل کرنے کی اجازت دیتا ہے۔ Refresh Token صرف پہلے لاگ ان پر جاری کیا جاتا ہے اور صارف اپنی Google اکاؤنٹ کی ترتیبات میں اسے منسوخ کر سکتا ہے۔

// سرور پر ID Token پروسیسنگ کی مثال (جعلی کوڈ)
fun verifyGoogleToken(idToken: String): User? {
    val verifier = GoogleIdTokenVerifier.Builder(
        NetHttpTransport(), GsonFactory.getDefaultInstance()
    ).setAudience(listOf(CLIENT_ID))
     .build()

    val token = verifier.verify(idToken) ?: return null
    val payload = token.payload

    return User(
        id = payload.subject,
        email = payload.email,
        name = payload.get("name") as String
    )
}

Refresh Token اور سیشن کا انتظام

سیکیورٹی کی سفارشات: ID Token کو کبھی بھی غیر محفوظ چینلز پر منتقل نہ کریں، تمام سرور درخواستوں کے لیے HTTPS استعمال کریں، ٹوکن کی میعاد ختم ہونے (exp فیلڈ) اور جاری کنندہ (iss) کو چیک کریں۔ کلائنٹ پر، ٹوکن کو بغیر انکرپشن کے SharedPreferences میں محفوظ نہ کریں — EncryptedSharedPreferences یا Android Keystore استعمال کریں۔ Google Sign-In سرور سے سرور کی تصدیق کے لیے نہیں ہے — اس کے لیے Service Accounts استعمال کریں۔

کوڈ مثال: Kotlin میں Google Sign-In انضمام

Credential Manager اور ViewModel کا استعمال کرتے ہوئے Android ایپ میں Google Sign-In انضمام کی ایک مکمل مثال۔ ایپ ایک سائن ان بٹن دکھاتی ہے، تصدیق کے بعد ID Token سرور کو بھیجتی ہے اور صارف کی معلومات دکھاتی ہے۔ کوڈ Credential Manager کے ساتھ غیر مطابقت پذیر کام کے لیے کوروٹینز استعمال کرتا ہے۔

class SignInViewModel: ViewModel() {
    private val cm = CredentialManager.create(getApplication())

    private val googleOption = GoogleIdCredentialOption.Builder()
        .setServerClientId(BuildConfig.SERVER_CLIENT_ID)
        .build()

    suspend fun signIn(): SignInResult {
        return try {
            val response = cm.getCredential(
                GetCredentialRequest.Builder()
                    .addCredentialOption(googleOption)
                    .build()
            )
            val credential = response.credential as GoogleIdCredential
            SignInResult.Success(credential.idToken)
        } catch (e: GetCredentialCancellationException) {
            SignInResult.Cancelled
        }
    }
}

sealed class SignInResult {
    data class Success(val idToken: String) : SignInResult()
    data class Error(val message: String) : SignInResult()
    data class Cancelled : SignInResult()
}

کامیاب تصدیق کے بعد، ایپ کو تصدیق اور سیشن بنانے کے لیے ID Token اپنے سرور کو بھیجنا چاہیے۔ HTTPS استعمال کرنے اور POST درخواست کے باڈی میں ٹوکن بھیجنے کی سفارش کی جاتی ہے۔ سرور اپنا سیشن ٹوکن واپس کرتا ہے، جسے کلائنٹ EncryptedSharedPreferences میں محفوظ کرتا ہے۔ سرور کو ہر بعد کی درخواست پر، Google ID Token کے بجائے اندرونی ٹوکن استعمال ہوتا ہے۔

عام انضمام کی غلطیاں اور حل

پہلی عام غلطی SHA-1 سرٹیفکیٹ کا مماثل نہ ہونا ہے۔ Google Cloud Console OAuth 2.0 Client ID کو SHA-1 سرٹیفکیٹ فنگر پرنٹ سے منسلک کرتا ہے۔ اگر ایپ ڈیبگ کلید سے بنائی گئی ہے لیکن Client ID ریلیز کلید کے لیے بنایا گیا تھا، تو Google Sign-In غلطی 12501 (SIGN_IN_FAILED) واپس کرے گا۔ حل: Google Cloud Console میں دونوں SHA-1 فنگر پرنٹس (ڈیبگ اور ریلیز) شامل کریں یا ڈیولپمنٹ کے لیے ایک Client ID اور پروڈکشن کے لیے علیحدہ Client ID استعمال کریں۔

دوسرا عام مسئلہ غلط serverClientId ہے۔ ڈویلپر اکثر Credential Manager کے serverClientId پیرامیٹر میں ویب ایپلیکیشن Client ID کی بجائے Android Client ID استعمال کرتے ہیں۔ Google کو سرور کی تصدیق کے لیے ID Token بنانے کے لیے بالکل ویب کلائنٹ ID درکار ہوتی ہے۔ Android Client ID صرف تصدیق کے دوران ایپ کی شناخت کے لیے استعمال ہوتی ہے۔ یقینی بنائیں کہ serverClientId Google Cloud Console میں ویب ایپلیکیشن سے مماثل ہے۔

تیسری غلطی منسوخی کی ہینڈلنگ کو نظر انداز کرنا ہے۔ صارف تصدیق مکمل کیے بغیر Google Sign-In ڈائیلاگ بند کر سکتا ہے۔ Credential Manager ایک GetCredentialCancellationException پھینکتا ہے جسے دیگر غلطیوں سے الگ سنبھالنا چاہیے۔ بہت سے ڈویلپر تمام استثنیات کو غلطیوں کے طور پر سنبھالتے ہیں، صارف کو “لاگ ان ناکام” پیغام دکھاتے ہیں جب کہ صارف نے صرف آپریشن منسوخ کیا تھا۔ صحیح ہینڈلنگ: منسوخی پر — کچھ نہ دکھائیں، صرف ابتدائی حالت میں واپس جائیں۔