Anda mungkin berada di sini karena Google Sign-In seharusnya telah menjadi integrasi 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 membangun dengan Capacitor, Ionic, Electron, atau stack web dan native yang campur aduk.
Bagian yang paling sering diabaikan oleh panduan adalah hal yang memecahkan implementasi nyata: ID Klien Google adalah spesifik platform, dan jenis aplikasi non-web seringkali tidak mendapatkan rahasia klien secara 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.
Daftar Isi
- Terhubung ke Aplikasi Anda dengan Ecosystem Google
- Apakah ID Klien Google?
- Cara Membuat dan Menampilkan ID Klien Anda
- Konfigurasi ID Klien Platform-Spesifik
- 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 sebuah API tiba-tiba tidak cukup lagi.
Karena itu, sign-in pengguna dan akses yang ditunjuk melalui OAuth. Google membutuhkan cara untuk mengidentifikasi aplikasi Anda, bukan hanya API yang dipanggil. Kredensial yang melakukan itu adalah ID Klien Google.
Jika Anda bekerja di dalam basis kode yang berplatform, kebingungan semakin cepat. 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, tapi mereka tidak harus memiliki identitas OAuth yang sama.
Konfigurasi OAuth yang praktis biasanya menyangkut beberapa pertanyaan implementasi:
- Apakah jenis aplikasi yang harus Anda buat
- Apakah Anda membutuhkan rahasia klien
- URIs atau asal yang harus cocok secara tepat
- Bagaimana menghubungkan aliran mobile dan web tanpa mencampurkan kredensial
- Why suatu aliran yang berfungsi di browser gagal di dalam wrapper native
Aturan praktis: Jika aplikasi Anda meminta izin pengguna atau sign-in, mulailah berpikir dalam jenis OAuth klien, bukan API kunci.
Perbedian 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 OAuth 2.0 Google adalah pengenal publik untuk aplikasi Anda di sistem autentikasi Google. Google menjelaskannya sebagai nama pengguna unik untuk aplikasi ketika meminta token akses dari endpoint autentikasi Google, dan menekankan bahwa itu berbeda dari API kunci karena digunakan dalam aliran OAuth untuk memverifikasi identitas aplikasi selama pertukaran token, seperti yang dijelaskan dalam documentasi klien OAuth Google Cloud.
Model Mental Sederhana
Pikirkan tentang ID Klien Google masalah sebagai username publik aplikasi Anda Menginformasikan Google, 'permintaan ini berasal dari aplikasi yang terdaftar ini.' Hal ini penting selama proses sign-in, persetujuan, pertukaran token, dan setiap alur di mana aplikasi Anda meminta untuk bertindak atas nama pengguna. ID klien dimaksudkan untuk disebutkan oleh aplikasi Anda dan server autentikasi Google..
Apa 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. __CAPGO_KEEP_0__ key
Mengidentifikasi proyek untuk beberapa API panggilan yang tidak melibatkan otorisasi pengguna yang didelegasikan. identifies a project for certain API calls that don’t involve delegated user authorization.
Rahasia Klien adalah lawan rahasia yang digunakan hanya dalam aliran dan jenis aplikasi yang dapat menjaga rahasia dengan aman.
Banyak integrasi yang rusak dimulai ketika seseorang menganggap hal ini sebagai variasi dari hal yang sama. Mereka bukan.
Dimana ID klien Google berada dalam prakteknya
Jika Anda membutuhkan Masuk dengan Google atau Bagaimana cara menggunakan ID klien Google dalam prakteknyaSatu Sentuhan
, 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.
Alasan mengapa setup ini terasa lebih ketat daripada menghasilkan kunci sederhana adalah karena Google tidak hanya memungkinkan akses. Itu mengikat permintaan autentikasi ke identitas aplikasi yang diketahui.
- Untuk tim yang membangun aplikasi hybrid, mental model yang paling aman adalah ini:
- Pakai ID klien untuk mengidentifikasi aplikasi
- Gunakan jenis aplikasi yang tepat untuk menentukan apakah rahasia itu termasuk dalam aliran
Jika Anda ingin primer yang lebih luas tentang bagaimana identitas aplikasi dan akses yang ditunjukkannya saling berhubungan, ini adalah panduan yang baik untuk memperbarui pengetahuan Anda. Bagaimana 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 > Klien dan jalur yang lebih tua APIs & Services > Kredensial seperti yang dijelaskan dalam panduan pengaturan Google Seseorang yang mengetik di laptop menampilkan konsol Google Cloud untuk membuat kredit OAuth 2.0 klien..
Mulai di area konsol yang tepat
Buka Google Cloud Console dan pilih atau buat proyek yang akan mengelola konfigurasi autentikasi. Jangan menyebarkan autentikasi ke proyek acak. Ini akan membuat proses audit dan dukungan menjadi lebih sulit nanti.
Setelah itu, 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 kredensial tanpa membatasi diri sendiri
Ketika Anda membuat klien OAuth baru, keputusan terbesar adalah jenis aplikasi Jenis aplikasi. Google meminta Anda untuk memilih jenis tertentu seperti Aplikasi Web, Aplikasi Android, iOS, atau Desktop. Pilihan itu tidak hanya estetika. Ini menentukan bagaimana aplikasi diidentifikasi dan apa konfigurasi dukungan yang diperlukan.
For a web app, harap masukkan:
- Authorized JavaScript origins
- Authorized redirect URIs
Nilai-nilai tersebut harus tepat. Untuk kredential web, Google mengharapkan skema dan hostname lengkap, seperti https://www.example.com, bukan konsep domain yang longgar.
For mobile platforms, bentuknya berbeda. Pendaftaran Android memerlukan identitas dan verifikasi kepemilikan level paket, sedangkan iOS menggunakan identifikator platform sendiri. Jika Anda menggabungkan autentikasi Google dengan lapisan autentikasi lainnya, ini contoh setup login sosial Capacitor dengan Supabase yang sering digunakan untuk menggabungkan bagian-bagian ini.
Jika Anda ingin membandingkan antarmuka pengguna saat Anda mengklik melalui:
Dimana Anda bisa menemukannya nanti
Setelah pembuatan, ID klien akan muncul di daftar kredit projek. Ruang projek 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 kredit ini dapat diatur secara efektif dalam waktu. Anda bisa kembali ke dashboard untuk menyalin ID klien, mengulas pengaturan, dan, jika relevan, mengelola rahasia klien terkait dengan kredit tersebut.
Layar persetujuan bukanlah dekorasi. Ini adalah bagian dari batasan kepercayaan. Pengguna melihat nama aplikasi Anda di sana, bukan nama projek internal Anda.
Konfigurasi ID Klien Platform-Spesifik
Cara termudah untuk menghancurkan pengaturan login Google adalah dengan asumsi ID klien dapat menutupi setiap 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 dalam Referensi Pengaturan Platform.
Mengapa aplikasi satu butuh ID klien yang berbeda
Aplikasi Anda mungkin satu aplikasi bagi pengguna, tapi itu berarti beberapa klien OAuth bagi Google.
A Aplikasi webdan pengembangan Androiddan 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 setiap platform model pendaftaran aplikasi sendiri.
Penyebutan yang terpisah itu adalah kebiasaan keamanan yang baik. Jika pengaturan kreditensial platform satu tertelan atau tidak terkonfigurasi dengan benar, platform lain tidak secara otomatis terpapar.
Berikut adalah pemisahan praktis yang harus diikuti:
- Web menggunakan ID klien web dan pemadanan asal dan URI redirect yang ketat.
- Pengembangan Android menggunakan ID klien Android yang terkait dengan identitas paket dan fingerprint SHA1.
- iOS menggunakan ID klien iOS yang terkait dengan identitas aplikasi.
- Desktop atau Electron sering menggunakan pola OAuth yang dipasang atau gaya desktop daripada aliran browser yang didukung rahasia.
Jenis ID Klien Google dibandingkan
| Jenis Aplikasi | Identifikasi Utama | Apakah Memberikan Rahasia Klien? | Penggunaan Utama |
|---|---|---|---|
| Web | Asal JavaScript yang diotorisasi dan URI redirect | Biasanya ya | Aplikasi browser dan OAuth web yang didukung backend |
| Android | Identitas paket plus fingerprint SHA1 | Sering tidak | Pengenalan aplikasi Android asli |
| iOS | Identitas paket aplikasi | Sering tidak | Pengenalan aplikasi iPhone dan iPad asli |
| 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 datang dengan baik keduanya ID klien dan kunci klien . Kemudian mereka membuat Kredensial Aplikasi Web karena itu adalah satu-satunya cara mereka bisa melihat rahasia di konsol. Aliran tampak lebih lengkap, jadi mereka terus melanjutkan. Kemudian, autentikasi gagal dalam cara yang membingungkan.
Menurut Penjelasan tentang kesalahan kredensial mobile, jenis aplikasi non-web seperti Android, iOS, dan aplikasi yang diinstal sering kali menerima ID klien tetapi tidak ada rahasia klien secara sengaja, karena Google tidak ingin rahasia yang dapat diakses oleh pengguna di dalam perangkat lunak sisi klien.
Keputusan desain tersebut benar. Aplikasi mobile atau bundle Electron bukanlah tempat penyimpanan rahasia yang aman.
Apa yang berhasil: Apa yang gagal:
Membuat kredensial web untuk aplikasi mobile hanya untuk memaksa rahasia ke dalam implementasi. Untuk __CAPGO_KEEP_0__ tim, hal ini biasanya muncul dalam salah satu dua pola buruk:
For Capacitor teams, this usually shows up in one of two bad patterns:
- dan kemudian mencoba berperilaku seperti server yang dapat diandalkan. Aplikasi mengirimkan __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__ ID Klien Google dari code yang diintegrasikan, yang menghilangkan tujuan memiliki rahasia.
Pendekatan yang 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 seharusnya dilakukan oleh klien publik.
Poin lain yang halus ini penting untuk sign-in Firebase Android. Dalam konfigurasi tersebut, ID klien aplikasi web digunakan sebagai ID klien OAuth server backend, sementara aplikasi Android menjaga identitas platform khususnya sendiri. Pembagian ini membingungkan tim karena mereka melihat keduanya kredential web dan kredential mobile di dalam proyek yang sama dan menganggap salah satu menggantikan yang lain. Tidak. Mereka memiliki peran yang berbeda.
Jika Anda ingat 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 banyak tidak disebabkan oleh serangan kompleks. Tim kehilangan kredential, memperluas pengaturan redirect yang terlalu luas, atau memasukkan rahasia ke tempat yang tidak aman sejak awal.
Pedoman OAuth Google menekankan bahwa ID klien dan rahasia harus dianggap sebagai data pribadi, dan untuk aplikasi web ID klien ditegakkan melawan URI redirect yang telah didaftarkan 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 di 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. Paket web, biner mobile, dan paket Electron dapat diperiksa oleh pengguna.
- Pendaftaran URI redirect yang tepat. Dekat tidak cukup. Google memvalidasi match yang ketat untuk aliran web.
- Tetapkan asal yang ketat. Tidak pernah mengizinkan domain yang luas hanya untuk menghindari gesekan setup.
- Pisahkan kredential platform. Jangan biarkan kemudahan memaksa Android, iOS, dan web menjadi satu kredential.
Detail operasional satu hal yang mudah dilupakan. Google memungkinkan tim untuk mengenerate rahasia baru untuk ID klien yang sudah ada dan menonaktifkan yang lama. Hal ini penting ketika rahasia terbuka atau ketika Anda memperketat proses pengembangan.
Apakah tim yang aman melakukan apa?
Tim yang tidak terjebak dalam masalah ini 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, panduan ini tentang mengelola rahasia di pipa CI/CD berlaku 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.
Memecahkan Kesalahan ID Klien yang Umum
Kebanyakan gagal OAuth Google berasal dari kesalahan pengaturan yang kecil. Teks kesalahan tidak selalu baik, tapi masalah dasar biasanya sederhana setelah Anda tahu di mana harus mencari.
Perbaikan yang dapat memperbaiki kebanyakan gagal
Panduan ini membantu Anda memahami cara mengatasi kesalahan yang umum pada ID klien Google OAuth.
redirect_uri_mismatch
Aplikasi Anda mengirimkan URI redirect yang tidak persis sama dengan yang terdaftar untuk klien web tersebut. Periksa skema, host, path, dan perbedaan apa pun yang mungkin ada di akhir. Pada OAuth web, matching yang tepat adalah bagian dari model keamanan.
invalid_client
Biasanya ini 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 pada aplikasi lintas-platform sering 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 sering menghilangkan rahasia secara sengaja, seperti yang dijelaskan dalam pembahasan tentang kesalahan rahasia klien . Jika implementasi Anda termasuk pekerjaan siklus token setelah sign-in, panduan revokasi itu juga berguna.
Sign-in Android gagal setelah pembuatan kredensial
Periksa kembali fingerprint SHA1 yang terikat pada klien Android. Jika identitas tanda tangan tidak sesuai dengan apa yang diharapkan Google, aplikasi tidak akan membuktikan kepemilikan dengan benar.
Jendela konfirmasi tampilan salah
Verifikasi nama aplikasi dan branding yang terkait dengan pengaturan OAuth di konsol. Pengguna mengizinkan 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 aliran sama sekali.
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 pembaruan yang sasaran ke aplikasi code dan asset tanpa harus menunggu tinjauan toko, yang membuatnya lebih mudah untuk memperbaiki aliran login, pengolahan panggilan balik, dan masalah autentikasi sisi klien ketika mereka masuk ke produksi.
