Anda mungkin berada di sini karena Sign-In Google seharusnya telah menjadi integrasi cepat, dan bukannya Anda berhadapan dengan layar kredit yang bingung mengapa satu jenis aplikasi memberikan 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 kredential yang salah hanya untuk memaksa rahasia ke dalam alur, Anda biasanya akan mengalami setup OAuth yang rusak dan lebih sulit untuk di-debug daripada yang seharusnya.
Daftar Isi
- Koneksi Aplikasi Anda ke Ecosystem Google
- Apakah ID Klien Google?
- Bagaimana 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.
Itu karena 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 sebuah 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
- Cara menghubungkan aliran mobile dan web tanpa mencampurkan kredensial
- Why sebuah aliran yang berfungsi di browser gagal di dalam wrapper native
Aturan praktis: Jika aplikasi Anda meminta izin pengguna atau login, mulai 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 , panduan ini pada 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 menggambarkannya sebagai username unik untuk aplikasi ketika meminta token akses dari endpoint autentikasi Google, dan menambahkan 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 nama pengguna 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..
Yang membuat orang kesulitan adalah bahwa kredensial 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 mengidentifikasi aplikasi dalam OAuth. 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 contextBagaimana cara menggunakan ID klien Google dalam prakteknya
Jika Anda membutuhkan
Masuk dengan Google
- atau
- Bagaimana cara menggunakan ID klien Google dalam prakteknya adalah dengan menggunakan ID klien untuk mengidentifikasi aplikasi dan menggunakan layar persetujuan untuk mewakili aplikasi kepada pengguna.
- 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 menyebar autentikasi ke proyek acak. Ini akan membuat proses audit dan dukungan menjadi menyakitkan 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 kredential 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, expect to enter:
- Authorized JavaScript origins
- Authorized redirect URIs
Nilai-nilai tersebut harus tepat. Untuk kredential web, Google mengharapkan skema dan hostname yang lengkap, seperti https://www.example.com, bukan konsep domain yang longgar.
For mobile platforms, the shape is different. Android registration requires package-level identity and ownership verification, while iOS uses its own platform identifiers. Jika Anda menggabungkan Google auth dengan lapisan autentikasi lainnya, ini contoh setup login sosial Capacitor dengan Supabase yang sering digunakan untuk menggabungkan bagian-bagian ini.
Jalur ini adalah referensi visual yang baik jika Anda ingin membandingkan antarmuka sementara Anda mengklik melalui:
Di mana Anda bisa menemukannya nanti
Setelah pembuatan, ID klien 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 terkelola secara waktu. Anda bisa kembali ke dashboard untuk menyalin ID klien, mengulas pengaturan, dan, di mana berlaku, 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 satu 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 pendirian Androiddan pendirian 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 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 pemadanan asal dan URI redirect yang ketat.
- Android Menggunakan ID klien Android yang terkait dengan identitas paket dan fingerprint SHA1.
- Menggunakan iOS Menggunakan ID klien iOS yang terkait dengan identitas aplikasi.
- Menggunakan Desktop atau Electron Sering menggunakan pola OAuth yang dipasang atau gaya desktop daripada aliran browser yang didasarkan rahasia.
Jenis ID Klien Google dibandingkan
| Jenis Aplikasi | Identifikasi Utama | Apakah Memberikan Rahasia Klien? | Penggunaan Utama |
|---|---|---|---|
| Menggunakan Web | Menggunakan asal JavaScript yang diotorisasi dan URI redirect. | Biasanya ya | Aplikasi browser dan OAuth web yang dipasang di backend |
| Android | Identitas paket plus fingerprint SHA1 | Biasanya tidak | Masuk Android native |
| iOS | Identitas bundle aplikasi | Biasanya tidak | Masuk iPhone dan iPad native |
| Desktop | Identitas aplikasi yang terpasang | Sering 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 kunci klien dan kunci klien. ID klien dan Kunci klien. Kemudian mereka membuat kredential Aplikasi Web karena itu adalah satu-satunya cara mereka bisa melihat rahasia di konsol. Aliran ini terlihat lebih lengkap, jadi mereka terus melanjutkan. Kemudian, autentikasi gagal dalam cara yang membingungkan. Menurut __CAPGO_KEEP_0__
__CAPGO_KEEP_1__ Penjelasan tentang kesalahan kredensial mobileJenis 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 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: Fluks OAuth sisi klien yang dirancang untuk klien publik.
Apa yang tidak berhasil: Membuat kredensial web untuk aplikasi mobile hanya untuk memaksa rahasia ke dalam implementasi.
Untuk tim Capacitor, biasanya ini muncul dalam salah satu dua pola buruk:
- Aplikasi meluncurkan fluks berbasis browser menggunakan klien web dan kemudian mencoba berperilaku seperti server rahasia. Aplikasi mengirimkan __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__ ID Klien Google Dari code yang diintegrasikan, yang menghilangkan tujuan dari memiliki rahasia.
Pendekatan yang lebih baik adalah menganggap aplikasi mobile dan desktop sebagai Klien Publik. Dalam OAuth modern, itu biasanya berarti menggunakan alur 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 Android yang didukung Firebase. 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 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 __CAPGO_KEEP_0__ berjalan, bukan bentuk kredential yang Anda inginkan
Mengamankan Kredensial Google __CAPGO_KEEP_0__ choose the client type that matches where the code runs, not the credential shape you wish you had.
Securing Your Google API Credentials
Mengamankan Kredensial Google __CAPGO_KEEP_0__
Guidan Google OAuth 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. Pengikat asal tersebut adalah bagian dari perlindungan terhadap intersepsi token, seperti yang dijelaskan di Panduan registrasi 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. Paket bundel web, biner mobile, dan paket Electron dapat diperiksa oleh pengguna.
- Daftarkan URI redirect yang tepat. Sama sekali tidak cukup. Google memvalidasi match yang ketat untuk aliran web.
- Tetapkan asal yang ketat. Jangan mengizinkan domain yang luas hanya untuk menghindari gesekan setup.
- Pisahkan kredensial platform. Jangan biarkan kemudahan memaksa Android, iOS, dan web menjadi satu kredit.
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.
Apakah tim yang aman melakukan?
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, panduan ini tentang mengelola rahasia di pipa CI/CD layak diterapkan pada pengaturan autentikasi Anda juga. 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.
Memecahkan Kesalahan ID Klien yang Umum
Kegagalan OAuth Google paling banyak disebabkan oleh kesalahan setup yang kecil. Teks kesalahan tidak selalu baik, tapi masalah dasar biasanya sederhana setelah Anda tahu di mana harus mencari.
Perbaikan yang dapat memperbaiki kegagalan paling banyak
Panduan ini membantu Anda memahami cara mengatasi kesalahan yang umum dan memperbaiki setup OAuth Anda.
redirect_uri_mismatch
Aplikasi Anda mengirimkan URI pengalihan yang tidak tepat sama sekali 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
Biasanya ini berarti aplikasi mengirimkan ID klien yang salah, rahasia yang salah untuk klien tersebut, atau mencampurkan kredential di antara platform. Contoh umum adalah aliran Android atau iOS yang tidak sengaja menggunakan kredential web di tempat yang salah.
invalid_request
Masalah ini luas, tetapi dalam 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
Langkah pertama untuk memeriksa 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 pembongkaran kesalahan rahasia klienJika implementasi Anda termasuk pekerjaan siklus token setelah sign-in, panduan revokasi itu juga berguna.
Sign-in Android gagal setelah pembuatan kredential
Periksa kembali fingerprint SHA1 yang dikaitkan dengan klien Android. Jika identitas tanda tangan tidak sesuai dengan apa yang diharapkan Google, aplikasi tidak akan membuktikan kepemilikan dengan benar.
Penampilan layar persetujuan tidak benar
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 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.
