Google Sign-In: ما هو، تسجيل الدخول عبر Google وOAuth 2.0 SDK

ما هو Google Sign-In؟

Google Sign-In هي خدمة تسجيل دخول موحد (Single Sign-On) تقدمها 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 (الحصول على Access Token)، والمصادقة السلسة (Silent Sign-In) للمستخدمين المصرح لهم بالفعل. يتطلب كل سيناريو مجموعة مختلفة من النطاقات (scopes) ويعيد أنواعاً مختلفة من الرموز.

كيف يعمل OAuth 2.0 في Google Sign-In

OAuth 2.0 هو بروتوكول تفويض يسمح للتطبيق بالحصول على وصول محدود إلى موارد المستخدم دون الكشف عن بيانات اعتماده. في سياق Google Sign-In، يعمل البروتوكول على النحو التالي: يطلب التطبيق التفويض من المستخدم عبر Google، ويتلقى رمز تفويض مؤقتاً، ويستبدله برموز وصول، ويستخدم هذه الرموز لاستدعاء واجهات برمجة تطبيقات Google.

الفرق الرئيسي لـ OAuth 2.0 عن البروتوكولات السابقة هو فصل الأدوار بين مالك المورد (المستخدم)، والعميل (التطبيق)، وخادم التفويض (Google)، وخادم الموارد (واجهة برمجة تطبيقات Google). لا يتلقى التطبيق أبداً كلمة مرور المستخدم — فقط رمز يمكن إلغاؤه. تستخدم Google Identity Platform مواصفة OpenID Connect فوق OAuth 2.0، مما يضيف ID Token موحداً بتنسيق JWT.

ID Token مقابل Access Token: الاختلافات

// مثال على الحصول على ID Token عبر Credential Manager
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)، وتوقيع للتحقق. يتحقق الجزء الخادم من التطبيق من توقيع ID Token باستخدام المفاتيح العامة لـ Google ويستخرج معرف المستخدم. يضمن هذا النهج أنه حتى إذا تم اختراق تطبيق العميل، لا يمكن للمهاجم تزوير الرمز دون الوصول إلى المفتاح الخاص لـ Google.

Credential Manager: طريقة جديدة لتسجيل الدخول على Android

Credential Manager هي واجهة برمجة تطبيقات Android حديثة تم تقديمها في عام 2023 تجمع جميع طرق المصادقة (Google Sign-In، تسجيل الدخول بكلمة المرور، Passkeys) في واجهة مستخدم واحدة. على عكس GoogleSignInClient القديم، لا يتطلب Credential Manager WebView لتسجيل الدخول — بل يستخدم Bottom Sheet أصلي، مما يسرع المصادقة ويحسن تجربة المستخدم.

الميزة الرئيسية لـ Credential Manager هي تجربة مستخدم موحدة لجميع أنواع بيانات الاعتماد. يرى المستخدم حواراً واحداً حيث يمكنه الاختيار: تسجيل الدخول عبر Google، استخدام Passkey، أو إدخال كلمة مرور. لا يحتاج المطور إلى إدارة تدفقات مصادقة مختلفة — Credential Manager يجرد التفاعل مع Google Sign-In وSmart Lock وPasskeys. توصي Google باستخدام Credential Manager كطريقة رئيسية لدمج Google Sign-In لنظام Android 14+.

الترحيل من GoogleSignInClient إلى Credential Manager

الترحيل من GoogleSignInClient إلى Credential Manager يتطلب تغيير منطق العميل: بدلاً من GoogleSignInOptions، استخدم GoogleIdCredentialOption، وبدلاً من GoogleSignIn.getSignedInAccountFromIntent، تعامل مع النتيجة عبر GetCredentialResponse. الجزء الخادم لا يتطلب تغييرات لأن ID Token يبقى بنفس تنسيق JWT. وفقاً لـ Google I/O 2024، حوالي 40% من التطبيقات على Google Play قد هاجرت بالفعل إلى Credential Manager.

إعداد Google Sign-In في مشروع Android

يبدأ دمج Google Sign-In في تطبيق Android بتكوين المشروع في Google Cloud Console. الخطوة الأولى هي إنشاء Client ID لـ OAuth 2.0 لنظام Android: تحديد package name للتطبيق وبصمة شهادة SHA-1. تستخدم Google هذه البيانات للتحقق من أن طلب المصادقة يأتي من تطبيقك وليس من عميل مزيف.

بعد إنشاء العميل في Google Cloud Console، يضيف المطور تبعية Credential Manager إلى build.gradle ويكوّن GoogleIdCredentialOption مع serverClientId. مهم: serverClientId هو Client ID لتطبيق الويب من نفس مشروع Google Cloud، والذي يستخدمه الخادم للتحقق من 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")

// طلب Google Sign-In عبر Credential Manager
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 على العميل، يرسله التطبيق إلى خادمه حيث يتم التحقق. يتحقق الخادم من توقيع JWT باستخدام المفاتيح العامة لـ Google (المتاحة على https://www.googleapis.com/oauth2/v3/certs)، ووقت انتهاء صلاحية الرمز (exp)، وقيمة حقل aud — يجب أن تتطابق مع serverClientId. بعد التحقق، ينشئ الخادم جلسته الخاصة، على سبيل المثال، إصدار JWT داخلي أو Session Token.

Google Sign-In على iOS: الإعداد والميزات

يتم دمج Google Sign-In على iOS عبر SDK GoogleSignIn-iOS، المتاح عبر CocoaPods أو Swift Package Manager. تتضمن عملية الإعداد إنشاء Client ID لنظام iOS في Google Cloud Console (تحديد Bundle Identifier)، وإضافة URL Scheme لاستدعاء الإرجاع، وتكوين AppDelegate لمعالجة عنوان URL الذي يعيده Google بعد المصادقة.

الفرق المهم في إصدار iOS من Google Sign-In عن Android هو الحاجة إلى تكوين URL Scheme وInfo.plist. يستخدم GoogleSDK Universal Links لاستدعاء الإرجاع، ولكن كخيار احتياطي، مطلوب URL Scheme بالشكل `com.googleusercontent.apps.[CLIENT_ID]`. مطلوب أيضاً تكوين Keychain Sharing لحفظ refresh token بين مرات تشغيل التطبيق. وفقاً لوثائق Google Identity، فإن SDK iOS يدعم iOS 15 وما فوق.

// إعداد Google Sign-In على iOS
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 باستعادة الجلسة تلقائياً إذا تم حفظ refresh token في Keychain. هذا مهم بشكل خاص للتطبيقات حيث لا يجب على المستخدم إعادة تسجيل الدخول في كل تشغيل. وفقاً لـ Google، ينجح Silent Sign-In في 85% من الحالات على الأجهزة ذات جلسة Google نشطة.

معالجة الرموز والأمان

الأمان في Google Sign-In مبني على ثلاثة مستويات: التحقق من العميل (توقيع SHA-1 للتطبيق)، وتشفير النقل (HTTPS/TLS)، والتوقيع المشفر JWT. ID Token المستلم من Google موقع باستخدام خوارزمية RS256 (RSA مع SHA-256). يجب على الجزء الخادم من التطبيق التحقق من توقيع الرمز، وانتهاء الصلاحية، والمُصدر (iss) — فقط accounts.google.com.

Access Token هو رمز مؤقت (يعيش ساعة واحدة) يوفر الوصول إلى واجهات برمجة تطبيقات Google (Google Drive، Google Calendar، YouTube، إلخ). على عكس ID Token، لا يحتوي Access Token على معلومات المستخدم — إنها سلسلة غير شفافة يستخدمها خادم واجهة برمجة تطبيقات Google لتفويض الطلبات. Refresh Token هو رمز طويل الأمد يسمح بالحصول على Access Tokens جديدة دون إعادة تسجيل دخول المستخدم. يتم إصدار 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 لذلك.

مثال كود: دمج Google Sign-In في Kotlin

مثال كامل لدمج Google Sign-In في تطبيق Android باستخدام Credential Manager وViewModel. يعرض التطبيق زر تسجيل الدخول، وبعد المصادقة يرسل ID Token إلى الخادم ويعرض معلومات المستخدم. يستخدم الكود coroutines للعمل غير المتزامن مع 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. في كل طلب لاحق للخادم، يتم استخدام الرمز الداخلي، وليس ID Token من Google.

الأخطاء الشائعة في الدمج وحلولها

الخطأ الشائع الأول هو عدم تطابق شهادة SHA-1. تربط Google Cloud Console Client ID لـ OAuth 2.0 ببصمة شهادة SHA-1. إذا تم بناء التطبيق بمفتاح تصحيح ولكن Client ID تم إنشاؤه لمفتاح إصدار، فسيعيد Google Sign-In الخطأ 12501 (SIGN_IN_FAILED). الحل: أضف كلاً من بصمتي SHA-1 (التصحيح والإصدار) في Google Cloud Console أو استخدم Client ID واحد للتطوير وآخر منفصل للإنتاج.

المشكلة الثانية الشائعة هي serverClientId غير صحيح. غالباً ما يستخدم المطورون Client ID Android بدلاً من Client ID تطبيق الويب في معامل serverClientId في Credential Manager. تتطلب Google بالضبط Client ID الويب لتوليد ID Token المخصص للتحقق من الخادم. Client ID Android يُستخدم فقط لتحديد التطبيق أثناء المصادقة. تأكد من أن serverClientId يتطابق مع تطبيق الويب في Google Cloud Console.

الخطأ الثالث هو تجاهل معالجة الإلغاء. قد يغلق المستخدم حوار Google Sign-In دون إكمال المصادقة. يطرح Credential Manager استثناء GetCredentialCancellationException يجب معالجته بشكل منفصل عن الأخطاء الأخرى. يعالج العديد من المطورين جميع الاستثناءات كأخطاء، ويعرضون للمستخدم رسالة “فشل تسجيل الدخول” عندما ألغى المستخدم العملية ببساطة. المعالجة الصحيحة: عند الإلغاء — لا تظهر شيئاً، فقط عد إلى الحالة الأولية.