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 نسبت به فرم email/رمز عبور 52% ثبت نام موفق‌تر نشان می‌دهند.

Google Sign-In از سه سناریو استفاده پشتیبانی می‌کند: احراز هویت کاربر (دریافت ID Token)، مجوز دسترسی به Google API (دریافت Access Token) و احراز هویت بدون ایجاد مزاحمت (Silent Sign-In) برای کاربرانی که قبلاً مجاز شده‌اند. هر سناریو به یک مجموعه مجوزهای مختلف (scopes) نیاز دارد و انواع مختلفی از توکن‌ها را برمی‌گرداند.

OAuth 2.0 در Google Sign-In چگونه کار می‌کند

OAuth 2.0 — یک پروتکل مجوزدهی است که به برنامه اجازه می‌دهد بدون افشای اطلاعات ورودی کاربر، به منابع آن دسترسی محدود داشته باشد. در زمینه Google Sign-In، پروتکل به این صورت کار می‌کند: برنامه از کاربر از طریق Google مجوز می‌خواهد، یک کد مجوز موقت دریافت می‌کند، آن را با توکن‌های دسترسی مبادله می‌کند و از این توکن‌ها برای فراخوانی Google API استفاده می‌کند.

تفاوت کلیدی OAuth 2.0 با پروتکل‌های قدیمی‌تر — تقسیم نقش‌ها بین مالک منبع (کاربر)، مشتری (برنامه)، سرور مجوزدهی (Google) و سرور منابع (Google API) است. برنامه هرگز رمز عبور کاربر را دریافت نمی‌کند — فقط یک توکن که قابل لغو است. 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) شامل سه بخش است: هدر با الگوریتم امضا، payload با داده‌های کاربر (sub، email، name، picture) و امضا برای تایید. بخش سرور برنامه امضای ID Token را با استفاده از کلیدهای عمومی Google بررسی می‌کند و شناسه کاربر را استخراج می‌کند. این رویکرد تضمین می‌دهد که حتی اگر برنامه مشتری در معرض خطر قرار گیرد، مهاجم نمی‌تواند بدون دسترسی به کلید خصوصی Google توکن را جعل کند.

Credential Manager: روش جدید ورود به Android

Credential Manager — یک API مدرن Android است که در سال 2023 معرفی شد و تمام روش‌های احراز هویت (Google Sign-In، ورود با رمز عبور، Passkeys) را در یک رابط کاربری واحد ترکیب می‌کند. بر خلاف GoogleSignInClient قدیمی، Credential Manager برای ورود به WebView نیاز ندارد — از Bottom Sheet سیستم عامل استفاده می‌شود که احراز هویت را سریع‌تر و تجربه کاربری را بهتر می‌کند.

مزیت اصلی Credential Manager — UX واحد برای همه انواع اعتبارنامه‌های ورودی است. کاربر یک کتره محاوره می‌بیند و می‌تواند انتخاب کند: ورود از طریق 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 آغاز می‌شود. گام اول — ایجاد OAuth 2.0 Client ID برای 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 (قابل دسترس در URL 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 است. Google SDK از Universal Links برای بازگشت استفاده می‌کند، اما برای fallback به URL Scheme به صورت `com.googleusercontent.apps.[CLIENT_ID]` نیاز است. همچنین برای ذخیره refresh token بین بارهای اجرایی برنامه، Keychain Sharing نیاز است. به گزارش مستندات Google Identity، iOS SDK از 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) امضا می‌شود. بخش سرور برنامه باید امضای توکن، انقضای آن و issuer (iss) را بررسی کند — فقط accounts.google.com.

Access Token — یک توکن موقت است (1 ساعت اعتبار دارد) که به Google API (Google Drive، Google Calendar، YouTube و غیره) دسترسی می‌دهد. بر خلاف ID Token، Access Token اطلاعاتی درباره کاربر ندارد — این یک رشته opaque است که سرور 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) و issuer (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 OAuth 2.0 Client ID را به اثر انگشت SHA-1 گواهینامه امضا می‌بندد. اگر برنامه با کلید debug ساخته شود اما Client ID برای کلید release ایجاد شده باشد، Google Sign-In خطای 12501 (SIGN_IN_FAILED) را برمی‌گرداند. راه حل — هر دو SHA-1 (debug و release) را در Google Cloud Console اضافه کنید یا از یک Client ID برای توسعه و یک جداگانه برای تولید استفاده کنید.

دومین مشکل رایج — serverClientId نادرست. توسعه‌دهندگان اغلب از Client ID Android به جای Client ID برنامه وب در پارامتر serverClientId Credential Manager استفاده می‌کنند. Google برای تولید ID Token مورد نظر برای تایید سرور، مجزاً به وب-کلینت ID نیاز دارد. Android Client ID فقط برای شناسایی برنامه در فرآیند احراز هویت استفاده می‌شود. مطمئن شوید serverClientId با برنامه وب در Google Cloud Console مطابقت دارد.

سومین خطا — نادیده گرفتن پردازش لغو. کاربر می‌تواند کتره Google Sign-In را بدون تکمیل احراز هویت ببندد. Credential Manager GetCredentialCancellationException را ایجاد می‌کند که باید جداگانه از سایر خطاها پردازش شود. بسیاری از توسعه‌دهندگان تمام استثناها را به عنوان خطا پردازش می‌کنند و پیام „ورود موفق نبود” را نشان می‌دهند، در حالی که کاربر صرفاً عملیات را لغو کرده است. پردازش صحیح: در صورت Cancelled — هیچ چیز نشان ندهید، فقط به وضعیت اولیه بازگردید.