Anda mungkin berada di sini karena Google Sign-In seharusnya telah menjadi integrasi yang cepat, dan bukannya Anda berhadapan dengan layar kredit yang bingung mengapa satu jenis aplikasi memberikan Anda rahasia klien dan yang lain tidak. Keterbingungan ini normal, terutama jika Anda sedang membangun dengan Capacitor, Ionic, Electron, atau stack web dan native yang campur aduk.
Bagian yang paling sering diabaikan oleh panduan adalah hal yang paling sering mengganggu implementasi nyata: ID Klien Google adalah spesifik platform, dan jenis aplikasi non-web sering kali tidak menerima ID klien rahasia oleh desain. Jika Anda membuat kredensial yang salah hanya untuk memaksa rahasia ke dalam alur, Anda biasanya akan menghadapi pengaturan OAuth yang rusak dan lebih sulit untuk di-debug daripada yang seharusnya.
Tabel Konten
- Menghubungkan Aplikasi Anda ke Ecosystem Google
- Apa Itu ID Klien Google
- Cara Membuat dan Menampilkan ID Klien Anda
- Konfigurasi ID Klien Khusus Platform
- Mengamankan Kredensial Google API Anda
- Mengatasi Kesalahan ID Klien yang Umum
Menghubungkan Aplikasi Anda ke Ecosystem Google
Banyak tim mengalami masalah ini pada saat yang sama. Mereka memerlukan Masuk dengan Google, atau mereka ingin akses yang disetujui pengguna ke sesuatu seperti Drive atau Kalender, dan kunci API tiba-tiba tidak cukup lagi.
Itu karena sign-in pengguna dan akses yang ditunjuk melalui OAuth. Google membutuhkan cara untuk mengidentifikasi aplikasi Anda, bukan hanya API yang sedang dipanggil. Kredensial yang melakukan itu adalah ID Klien Google.
Jika Anda bekerja di kodebase lintas-platform, kebingungan semakin parah. Anda mungkin memiliki frontend web, shell Android, aplikasi iOS, dan mungkin juga build Electron untuk desktop. Mereka mungkin memiliki branding produk dan logika backend yang sama, tetapi mereka tidak seharusnya memiliki identitas OAuth yang sama.
Konfigurasi OAuth yang praktis biasanya menurun ke beberapa pertanyaan implementasi:
- Apakah Anda harus membuat jenis aplikasi mana
- Apakah Anda membutuhkan rahasia klien
- URIs atau asal yang harus cocok secara tepat
- Cara menghubungkan aliran mobile dan web tanpa mencampurkan kredential
- Why sebuah aliran yang berfungsi di browser gagal di dalam wrapper native
Aturan praktis: Jika aplikasi Anda meminta izin pengguna atau sign-in, mulai dengan berpikir dalam jenis OAuth klien, bukan API kunci.
Perbedaan itu menyelamatkan waktu awal. Ini juga mencegah kesalahan umum pembangunan aliran login mobile sekitar kredential web hanya karena konsol menampilkan lebih banyak bidang. Jika Anda menerapkan ini di aplikasi Capacitor ini, panduan tentang OAuth2 di aplikasi Capacitor adalah teman yang berguna untuk aliran aplikasi.
Apa itu ID Klien Google
A ID Klien Google adalah pengenal publik untuk aplikasi Anda di sistem autentikasi Google. Google menggambarkannya sebagai username unik untuk aplikasi ketika meminta token akses dari endpoint autentikasi Google, dan menekankan bahwa itu berbeda dari __CAPGO_KEEP_0__ kunci karena digunakan dalam aliran OAuth untuk memverifikasi identitas aplikasi selama pertukaran token, seperti yang dijelaskan dalam is the public identifier for your application in Google’s auth system. Google describes it as the unique username for an application when requesting access tokens from Google authentication endpoints, and notes that it’s distinct from API keys because it’s used in OAuth flows to verify the app’s identity during token exchange, as explained in Diagram yang menjelaskan bahwa ID Klien Google berfungsi sebagai pengenal unik dan lapisan keamanan untuk aplikasi..
Model Mental Sederhana
Bayangkanlah aplikasi ID Klien Google Masalah-masalah tersebut dapat dianggap sebagai aplikasi Anda Nama Pengguna Publik.
Itu memberitahu Google, “permintaan ini berasal dari aplikasi yang telah terdaftar ini.” Hal ini sangat penting selama proses masuk, persetujuan, pertukaran token, dan setiap alur yang meminta aplikasi Anda untuk bertindak atas nama pengguna. ID Klien dimaksudkan untuk disebutkan oleh aplikasi Anda dan server autentikasi Google.
Yang membuat orang kesulitan adalah bahwa kredential ini berada di samping dua konsep lain yang tidak dapat diganti-gantikan.
ID Klien mengidentifikasi aplikasi dalam OAuth.
API key mengidentifikasi proyek untuk beberapa API panggilan yang tidak melibatkan otorisasi pengguna yang didelegasikan.
Rahasia Klien adalah lawan rahasia yang digunakan hanya dalam aliran dan jenis aplikasi yang dapat aman menjaga rahasia.
Banyak integrasi yang rusak dimulai ketika seseorang menganggap hal ini sebagai variasi dari hal yang sama. Mereka tidak.
Dimana ID klien Google masuk dalam prakteknya
Jika Anda membutuhkan Masuk dengan Google atau One Tap, ID klien adalah nilai yang digunakan frontend untuk memulai tangan shake autentikasi. Dokumentasi Google juga mencatat bahwa aplikasi harus terdaftar dalam proyek Cloud Console yang khusus sebelum kredential dapat dihasilkan, dan bahwa aplikasi web memerlukan asal JavaScript yang dikonfigurasi atau URI redirect dengan skema dan hostname yang lengkap.
Itu mengapa pengaturan terasa lebih ketat daripada menghasilkan kunci sederhana. Google tidak hanya memungkinkan akses. Itu mengikat permintaan autentikasi ke identitas aplikasi yang diketahui.
Untuk tim yang membangun aplikasi hybrid, model mental yang paling aman adalah ini:
- Gunakan ID klien untuk mengidentifikasi aplikasi
- Gunakan layar persetujuan untuk mewakili aplikasi kepada pengguna
- Gunakan jenis aplikasi yang benar untuk menentukan apakah rahasia itu termasuk dalam aliran
Jika Anda ingin primer yang lebih luas tentang bagaimana identitas aplikasi dan akses yang ditunjukkannya berinteraksi, panduan autentikasi aplikasi ini adalah refresher yang baik.
Cara Membuat dan Menampilkan ID Klien Anda
Jalur console telah berubah cukup banyak sehingga pengembang sering berpikir mereka berada di tempat yang salah. Mereka biasanya tidak. Google saat ini menampilkan dua jalur navigasi untuk kredit ini: jalur yang lebih baru Google Auth Platform > Clients dan jalur yang lebih tua APIs & Services > Credentials path, seperti yang dijelaskan dalam.
Mulai di area konsol yang tepat
Buka Google Cloud Console dan pilih atau buat proyek yang akan mengelola konfigurasi autentikasi. Jangan menyebar autentikasi ke proyek acak. Ini akan membuat proses audit dan dukungan menjadi menyakitkan nanti.
Dari sana, pergi ke salah satu tempat berikut:
- Google Auth Platform > Klien
- APIs & Services > Kredensial
If your team sees different navigation labels, that’s expected. Google has been separating identity setup from the rest of the API credential surface.
Buat kredential tanpa membatasi diri sendiri
Saat Anda membuat klien OAuth baru, keputusan terbesar adalah jenis aplikasi. Google meminta Anda untuk memilih jenis tertentu seperti Web, Android, iOSatau DesktopPilihan itu bukanlah hal estetis. Ia menentukan bagaimana aplikasi diidentifikasi dan apa konfigurasi dukungan yang diperlukan.
Untuk aplikasi web, harap masukkan:
- Asal JavaScript yang Dijalankan dengan Izin
- URI Pengalihan yang Dijalankan dengan Izin
Nilai-nilai tersebut harus tepat. Untuk kredential web, Google mengharapkan skema dan hostname yang lengkap, seperti https://www.example.com, rather than a loose domain concept.
daripada konsep domain yang longgar. this Capacitor social login setup with Supabase pengaturan login sosial ini dengan Supabase __CAPGO_KEEP_0__ adalah contoh berguna bagaimana bagian-bagian ini seringkali saling melengkapi.
Jika Anda ingin membandingkan antarmuka pengguna saat Anda mengklik melalui:
Dimana Anda bisa menemukannya nanti
Setelah pembuatan, ID klien muncul di daftar kreditensi proyek. Ruang proyek yang sama juga di mana tim mengaktifkan API dan melihat bagaimana identitas OAuth terkait dengan layar persetujuan. Nama aplikasi yang terdaftar adalah apa yang pengguna lihat selama prompt izin, yang merupakan alasan mengapa penting untuk menamai aplikasi dengan akurat.
Google menjaga kreditensi ini dapat diatur secara berkelanjutan. Anda bisa kembali ke dashboard untuk menyalin ID klien, mengulas pengaturan, dan, jika berlaku, mengelola rahasia klien terkait dengan kreditensi tersebut.
Layar persetujuan bukanlah dekorasi. Ini adalah bagian dari batasan kepercayaan. Pengguna melihat nama aplikasi Anda di sana, bukan nama proyek internal Anda.
Konfigurasi ID Klien Platform-Spesifik
Cara termurah untuk menghancurkan pengaturan login Google adalah dengan asumsi satu ID klien dapat menutupi semua platform. Tidak bisa. Untuk aplikasi multi-platform, setiap platform harus mendaftarkan ID klien OAuth 2.0 yang unik, dan pengaturan Android secara khusus memerlukan fingerprint SHA1 untuk memverifikasi kepemilikan, seperti yang disebutkan di referensi pengaturan platform ini.
Mengapa aplikasi satu butuh ID klien yang berbeda
Produk Anda mungkin adalah satu aplikasi bagi pengguna, tapi itu adalah beberapa klien OAuth bagi Google.
A Aplikasi weban pengembangan Androidan pengembangan iOSdan sebuah aplikasi desktop tidak menampilkan sifat keamanan yang sama. Mereka tidak membuktikan identitas dengan cara yang sama, dan mereka tidak semua menyimpan kreditensial di lingkungan yang dapat dipercaya. Google mengatasi hal itu dengan memberikan model pendaftaran aplikasi untuk setiap platform.
Pengaturan yang terpisah itu adalah kebiasaan keamanan yang baik. Jika pengaturan kreditensial satu platform terganggu atau tidak terkonfigurasi dengan benar, yang lain tidak secara otomatis terbuka.
Berikut adalah pemisahan yang praktis untuk diikuti:
- Web menggunakan ID klien web dan pencocokan asal dan URI redirect yang ketat.
- Android menggunakan ID klien Android yang terkait dengan identitas paket dan fingerprint SHA1.
- iOS menggunakan ID klien iOS yang terkait dengan identitas bundle aplikasi.
- Desktop atau Electron sering menggunakan pola OAuth yang dipasang atau gaya desktop daripada aliran browser yang didukung rahasia.
Jenis ID Klien Google dibandingkan
| Tipe Aplikasi | Identifikasi Utama | Apakah Memberikan Rahasia Klien? | Kasus Penggunaan Utama |
|---|---|---|---|
| Web | Asal JavaScript yang Diberi Izin dan URI Redirect | Biasanya ya | Aplikasi browser dan OAuth web yang didukung backend |
| Android | Identitas paket plus fingerprint SHA1 | Sering tidak | Masuk Android native |
| iOS | Identitas paket aplikasi | Sering tidak | Masuk iPhone dan iPad native |
| Desktop | Identitas aplikasi yang terpasang | Banyak kali tidak | Aplikasi desktop, termasuk aliran native Electron-style |
Paradoks kunci klien untuk mobile dan desktop
Ini adalah bagian yang banyak tutorial salah
Para pengembang mobile dan desktop sering kali mengharapkan setiap klien OAuth untuk datang dengan baik ID klien dan kunci klien. Kemudian mereka membuat Kredensial Aplikasi Web karena itu adalah satu-satunya cara mereka dapat melihat rahasia di konsol. Aliran ini terlihat lebih lengkap, jadi mereka terus melanjutkan. Kemudian, autentikasi gagal dalam cara yang membingungkan.
Menurut penjelasan kesalahan kreditur ponselTipe aplikasi non-web seperti Android, iOS, dan aplikasi terpasang sering kali menerima ID klien tetapi tidak ada rahasia klien secara sengaja, karena Google tidak ingin rahasia yang dapat diandalkan tersembunyi di perangkat lunak sisi klien di mana pengguna dapat mengekstraknya.
Pilihan desain tersebut benar. Aplikasi ponsel atau bundle Electron bukanlah tempat penyimpanan rahasia yang aman.
Apa yang berhasil: Aliran OAuth sisi klien yang dirancang untuk klien publik.
Apa yang tidak berhasil: Membuat kreditur web untuk aplikasi ponsel hanya untuk memaksa rahasia ke dalam implementasi.
Untuk Capacitor tim, hal ini biasanya muncul dalam salah satu dua pola buruk:
- Aplikasi meluncurkan aliran berbasis browser menggunakan klien web dan kemudian mencoba berperilaku seperti server yang dapat diandalkan.
- Aplikasi mengirimkan kunci klien dari code yang dikemas, yang mengalahkan tujuan memiliki rahasia.
Sangat lebih baik adalah menganggap aplikasi mobile dan desktop sebagai klien publik. Dalam OAuth modern, itu biasanya berarti menggunakan aliran yang tidak bergantung pada rahasia yang disembunyikan di dalam klien. Jika backend Anda terlibat, jaga operasi rahasia di backend dan jaga aplikasi native terbatas pada apa yang harus dilakukan oleh klien publik.
Poin yang halus lainnya yang penting untuk Firebase-backed Android sign-in. Dalam konfigurasi tersebut, ID klien aplikasi web digunakan sebagai ID klien OAuth server backend, sementara aplikasi Android menjaga identitas platform khususnya sendiri. Pembagian itu membingungkan tim karena mereka melihat keduanya kredential web dan kredential mobile di proyek yang sama dan menganggap salah satu menggantikan yang lain. Tidak. Mereka memiliki peran yang berbeda.
Jika Anda mengingat satu aturan, gunakan aturan ini: pilih jenis klien yang sesuai dengan tempat code berjalan, bukan bentuk kredential yang Anda inginkan..
Mengamankan Kredensial Google API
Insiden OAuth paling tidak disebabkan oleh serangan kompleks. Tim kehilangan kredential, memperluas pengaturan redirect yang terlalu luas, atau memasukkan rahasia ke tempat-tempat di mana mereka tidak pernah aman.
Guidanannya OAuth Google menekankan bahwa ID klien dan rahasia harus dianggap sebagai data pribadi, dan untuk aplikasi web ID klien diterapkan terhadap URI redirect yang telah diregistrasi sebelumnya. Jika URI redirect tidak sepenuhnya cocok, Google menolak permintaan. Pemetaan asal yang merupakan bagian dari perlindungan terhadap intersepsi token, seperti yang dijelaskan di Pedoman pendaftaran klien OAuth.com.
Apa yang harus ditutup segera
Jika Anda hanya melakukan beberapa hal dengan benar, lakukan hal-hal ini:
- Tidak pernah mengirimkan rahasia klien dalam aplikasi code. Bundel web, biner mobile, dan paket Electron dapat diperiksa oleh pengguna.
- Daftarkan URI redirect yang tepat. Cukup tidaklah cukup. Google memvalidasi match yang ketat untuk aliran web.
- Tetapkan asal yang ketat. Jangan mengizinkan domain yang luas hanya untuk menghindari gesekan setup.
- Sisihkan kredensial platform. Jangan biarkan kemudahan memasukkan Android, iOS, dan web ke dalam satu kredential.
Detail operasional satu hal yang mudah dilupakan. Google memungkinkan tim untuk menghasilkan rahasia baru untuk ID klien yang sudah ada dan mematikan yang lama. Hal ini penting ketika rahasia terbuka atau ketika Anda memperketat proses pengiriman.
Apa yang dilakukan tim yang aman secara nyata.
Tim yang tetap aman menganggap kredential OAuth seperti rahasia produksi lainnya.
Mereka menyimpan rahasia klien web di backend, menginjeksinya melalui manajemen lingkungan, dan memantau siapa yang memiliki akses konsol. Jika Anda membersihkan pipa rilis Anda, panduan ini tentang manajemen rahasia dalam pipa CI/CD bernilai juga untuk pengaturan autentikasi Anda.
Mereka juga memeriksa metadata, bukan hanya kunci. Layar persetujuan OAuth terkait dengan identitas klien yang dilihat pengguna. Jika nama aplikasi tidak jelas atau menipu, pengguna lebih cenderung tidak percaya atau menyetujui aplikasi yang salah.
Keamanan bukan hanya tentang menyembunyikan rahasia. Ini juga tentang memastikan identitas aplikasi yang tepat, target redirect, dan layar persetujuan selalu berjalan dengan baik.
Pengaturan Masalah Client ID yang Umum
Kebanyakan gagal OAuth Google berasal dari kesalahan pengaturan yang kecil. Teks kesalahan tidak selalu baik, tetapi masalah dasar biasanya sederhana sekali setelah Anda tahu di mana harus mencari.
Pemecahan masalah yang menyelesaikan kebanyakan gagal
redirect_uri_mismatch
Aplikasi Anda mengirimkan URI pengalihan yang tidak sepenuhnya sesuai dengan yang terdaftar untuk klien web tersebut. Periksa skema, host, path, dan perbedaan apa pun yang mungkin ada di akhir. Untuk OAuth web, matching yang tepat adalah bagian dari model keamanan.
invalid_client
Hal ini biasanya berarti aplikasi mengirimkan ID klien yang salah, rahasia yang salah untuk klien tersebut, atau mencampurkan kredensial di antara platform. Contoh umum adalah aliran Android atau iOS yang tidak sengaja menggunakan kredensial web di tempat yang salah.
invalid_request
Masalah ini luas, tetapi dalam aplikasi lintas-platform, sering kali menunjukkan parameter autentikasi yang rusak atau aliran yang tidak sesuai dengan jenis klien. Periksa apakah aplikasi mencoba menyertakan rahasia di tempat yang tidak seharusnya, atau apakah aliran OAuth yang dipilih mengharapkan jenis klien yang berbeda.
Google Sign-In bekerja di web tetapi gagal di mobile
Hal pertama yang perlu diperiksa adalah jenis klien. Sumber kesalahan yang paling umum bagi pengembang mobile adalah membuat ID klien aplikasi web hanya untuk mendapatkan rahasia klien, ketika mereka seharusnya menggunakan jenis Android atau iOS yang seringkali mengabaikan rahasia secara sengaja, seperti yang dijelaskan dalam pembalikkan rahasia klien yang salahJika implementasi Anda termasuk pekerjaan siklus token setelah sign-in, panduan penghapusan token juga berguna.
Gagal sign-in Android setelah pembuatan kredensial
Periksa kembali fingerprint SHA1 yang terpasang pada klien Android. Jika identitas tanda tangan tidak sesuai dengan apa yang diharapkan Google, aplikasi tidak akan membuktikan kepemilikan dengan benar.
Tampilan layar persetujuan terlihat salah
Verifikasi nama aplikasi dan branding yang terkait dengan pengaturan OAuth di konsol. Pengguna mengotorisasi apa yang mereka lihat di sana, sehingga metadata yang salah menciptakan masalah kepercayaan dan kebisingan dukungan.
Urutan debugging yang praktis adalah sederhana: periksa jenis klien terlebih dahulu, kemudian pengaturan redirect, kemudian identifikasi platform, kemudian apakah rahasia termasuk dalam alur atau tidak.
Jika tim Anda mengirimkan Capacitor atau aplikasi Electron, bug autentikasi jarang tetap isolasi. Mereka biasanya muncul bersamaan dengan tekanan rilis, kebutuhan rollback, dan perbaikan lingkungan spesifik. Capgo membantu tim mengirimkan update yang sasaran ke aplikasi code dan aset tanpa menunggu ulasan toko, yang membuatnya lebih mudah untuk memperbaiki alur login, pengolahan panggilan balik, dan masalah autentikasi sisi klien ketika mereka masuk ke produksi.
