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, εξασφαλίζοντας τη λήψη δεδομένων ταυτότητας του χρήστη: όνομα, email, avatar και μοναδικό αναγνωριστικό.

Σε αντίθεση με την παραδοσιακή αυθεντικοποίηση μέσω email και κωδικού, το Google Sign-In εξαλείφει την ανάγκη να θυμάστε κωδικούς και να περάσετε από τη διαδικασία εγγραφής. Ο χρήστης επιλέγει έναν λογαριασμό Google στη συσκευή, επιβεβαιώνει τα δικαιώματα, και η εφαρμογή λαμβάνει ένα token πρόσβασης. Σύμφωνα με Google Identity Platform (2025), οι εφαρμογές με Google Sign-In εμφανίζουν 52% περισσότερες επιτυχείς εγγραφές σε σύγκριση με τη φόρμα email/κωδικού.

Το Google Sign-In υποστηρίζει τρεις σενάρια χρήσης: αυθεντικοποίηση χρήστη (λήψη ID Token), εξουσιοδότηση πρόσβασης στο Google API (λήψη Access Token) και απρόσκοπτη αυθεντικοποίηση (Silent Sign-In) για ήδη εξουσιοδοτημένους χρήστες. Κάθε σενάριο απαιτεί διαφορετικό σύνολο δικαιωμάτων (scopes) και επιστρέφει διαφορετικούς τύπους tokens.

Πώς λειτουργεί το OAuth 2.0 στο Google Sign-In

OAuth 2.0 — είναι ένα πρωτόκολλο εξουσιοδότησης που επιτρέπει στην εφαρμογή να αποκτήσει περιορισμένη πρόσβαση στους πόρους του χρήστη χωρίς να αποκαλύψει τα διαιτηρήρια σύνδεσής του. Στο πλαίσιο του Google Sign-In, το πρωτόκολλο λειτουργεί ως εξής: η εφαρμογή ζητά εξουσιοδότηση από τον χρήστη μέσω Google, λαμβάνει έναν προσωρινό κωδικό εξουσιοδότησης, τον ανταλλάσσει με tokens πρόσβασης και χρησιμοποιεί αυτά τα tokens για να καλέσει το Google API.

Η βασική διαφορά του OAuth 2.0 από παλαιότερα πρωτόκολλα — ο διαχωρισμός ρόλων μεταξύ του ιδιοκτήτη πόρου (χρήστης), του πελάτη (εφαρμογή), του διακομιστή εξουσιοδότησης (Google) και του διακομιστή πόρων (Google API). Η εφαρμογή ποτέ δεν λαμβάνει τον κωδικό του χρήστη — μόνο ένα token που μπορεί να ανακληθεί. Η 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 και εξάγει τον αναγνωριστικό του χρήστη. Αυτή η προσέγγιση εγγυάται ότι, ακόμα και αν η εφαρμογή-πελάτης διακυβευτεί, ο επιτιθέμενος δεν μπορεί να πλαστογραφήσει το token χωρίς πρόσβαση στο ιδιωτικό κλειδί της Google.

Credential Manager: νέος τρόπος σύνδεσης σε Android

Credential Manager — είναι ένα σύγχρονο Android API, που παρουσιάστηκε το 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 project

Η ενσωμάτωση του 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. Η εφαρμογή-πελάτης δεν επαληθεύει το 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), τη διάρκεια ισχύος του token (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]`. Επίσης απαιτείται διαμόρφωση Keychain Sharing για την αποθήκευση refresh token μεταξύ εκκινήσεων της εφαρμογής. Σύμφωνα με την τεκμηρίωση 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.

Διαχείριση tokens και ασφάλεια

Ασφάλεια του Google Sign-In βασίζεται σε τρία επίπεδα: επαλήθευση πελάτη (υπογραφή SHA-1 της εφαρμογής), κρυπτογράφηση μεταφοράς (HTTPS/TLS) και κρυπτογραφική υπογραφή JWT. Το ID Token που λαμβάνεται από τη Google υπογράφεται χρησιμοποιώντας τον αλγόριθμο RS256 (RSA με SHA-256). Το μέρος του εξυπηρετητή της εφαρμογής πρέπει να ελέγχει την υπογραφή του token, τη διάρκεια ισχύος και τον εκδότη (iss) — μόνο accounts.google.com.

Access Token — είναι ένα προσωρινό token (ισχύει για 1 ώρα) που παρέχει πρόσβαση στο Google API (Google Drive, Google Calendar, YouTube κ.λ.). Σε αντίθεση με το ID Token, το Access Token δεν περιέχει πληροφορίες για τον χρήστη — είναι μια opaque συνταριθμετσειρά που χρησιμοποιεί ο εξυπηρετητής Google API για εξουσιοδότηση του αιτήματος. Refresh Token — ενα μακρόβιο 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 για όλα τα αιτήματα στον εξυπηρετητή, ελέγχετε τη διάρκεια ισχύος του token (πεδίο exp) και τον εκδότη (iss). Στον πελάτη, μην αποθηκεύετε tokens σε 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 και η μεταφορά του token στο σώμα του αιτήματος POST. Ο εξυπηρετητής επιστρέφει το δικό του token συνεδρίας, το οποίο ο πελάτης αποθηκεύει στο EncryptedSharedPreferences. Σε κάθε επόμενο αίτημα στον εξυπηρετητή χρησιμοποιείται το εσωτερικό token, όχι το Google ID Token.

Συνηθισμένα λάθη κατά την ενσωμάτωση και η λύση τους

Πρώτο συνηθισμένο λάθος — αναντιστοιχία 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. Οι πραγματοποιητές χρησιμοποιούν συχνά Android Client ID αντί για Client ID της διαδικτυακής εφαρμογής στην παράμετρο serverClientId του Credential Manager. Η Google απαιτεί ακριβώς το web-client ID για τη δημιουργία ID Token που προορίζεται για επαλήθευση από τον εξυπηρετητή. Το Android Client ID χρησιμοποιείται μόνο για την αναγνώριση της εφαρμογής στη διαδικασία αυθεντικοποίησης. Ελέγξτε αν το serverClientId αντιστοιχεί στη διαδικτυακή εφαρμογή στο Google Cloud Console.

Τρίτο λάθος — αγνόηση χειρισμού ακύρωσης. Ο χρήστης μπορεί να κλείσει το παράθυρο Google Sign-In χωρίς να ολοκληρώσει την αυθεντικοποίηση. Το Credential Manager ρίχνει GetCredentialCancellationException που πρέπει να χειριστεί ξεχωριστά από άλλα σφάλματα. Πολλοί πραγματοποιητές χειρίζονται όλες τις εξαιρέσεις ως σφάλματα και εμφανίζουν στον χρήστη το μήνυμα “Η σύνδεση απέτυχε”, ενώ ο χρήστης απλώς ακύρωσε την επιχείρηση. Σωστός χειρισμός: σε Cancelled — μην εμφανίζετε τίποτα, απλώς επιστρέψτε στην αρχική κατάσταση.