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 banyak panduan lewatkan adalah hal yang paling sering mengganggu implementasi nyata: ID Klien Google adalah spesifik platform, dan jenis aplikasi non-web seringkali tidak menerima rahasia klien oleh desain. Jika Anda membuat kredensial yang salah hanya untuk memaksa rahasia ke dalam aliran, Anda biasanya akan berakhir dengan pengaturan OAuth yang rusak yang lebih sulit untuk di-debug daripada yang seharusnya.
Daftar Isi
- Menghubungkan Aplikasi Anda ke Ecosystem Google
- Apa itu ID Klien Google
- Cara Membuat dan Menampilkan ID Klien Anda
- Konfigurasi Klien ID 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 dipanggil. Kredensial yang melakukan itu adalah ID Klien Google.
Jika Anda bekerja dalam 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 harus memiliki identitas OAuth yang sama.
Konfigurasi OAuth yang praktis biasanya menurunkan 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 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
Pikirkan tentang ID Klien Google Masalah sebagai username publik aplikasi Anda Itu memberitahu Google, “permintaan ini datang dari aplikasi yang terdaftar ini.” Hal itu penting selama proses sign-in, persetujuan, pertukaran token, dan setiap alur di mana aplikasi Anda meminta untuk bertindak atas nama pengguna..
ID Klien
Mengidentifikasi aplikasi dalam OAuth.
__CAPGO_KEEP_0__ key Mengidentifikasi proyek untuk beberapa __CAPGO_KEEP_0__ panggilan yang tidak melibatkan otorisasi pengguna yang didelegasikan.
API key identifies a project for certain API calls that don’t involve delegated user authorization.
__CAPGO_KEEP_0__ key 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 tidak.
Dimana ID klien Google masuk dalam prakteknya
Jika Anda membutuhkan Masuk dengan Google atau Tap Satu, 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 setup 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:
- Pakai ID klien untuk mengidentifikasi aplikasi
- Pakai layar persetujuan untuk mewakili aplikasi kepada pengguna
- Gunakan jenis aplikasi yang benar untuk menentukan apakah rahasia tersebut termasuk dalam aliran
Jika Anda ingin primer yang lebih luas tentang bagaimana identitas aplikasi dan akses yang didelegasikan saling berhubungan, panduan autentikasi aplikasi ini adalah pilihan yang baik untuk memperbarui pengetahuan Anda.
Cara Membuat dan Menampilkan ID Klien Anda
Jalan pintas konsol telah berubah cukup banyak sehingga pengembang sering berpikir mereka berada di tempat yang salah. Mereka biasanya tidak. Google saat ini menampilkan dua rute navigasi untuk kredit ini: rute yang lebih baru Google Auth Platform > Klien dan rute yang lebih tua APIs & Services > Kredensial jika Anda merujuk pada Dokumentasi pengaturan Google.
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
Jika tim Anda melihat label navigasi yang berbeda, itu diharapkan. Google telah memisahkan pengaturan identitas dari permukaan kredensial API lainnya.
Buat kredensial tanpa membatasi diri sendiri
Ketika Anda membuat klien OAuth baru, keputusan terbesar adalah jenis aplikasi. Google meminta Anda untuk memilih jenis tertentu seperti Web, Android, iOSatau DesktopPilihan itu tidak hanya estetika. Membuat identifikasi aplikasi dan konfigurasi dukungan yang diperlukan.
Untuk aplikasi web, harap masukkan:
- Asal JavaScript yang Dijamin Otorisasi
- URI Pengalihan yang Dijamin Otorisasi
Nilai-nilai tersebut harus tepat. Untuk kredential web, Google mengharapkan skema dan hostname yang lengkap, seperti https://www.example.comdan bukan konsep domain yang longgar.
Untuk platform mobile, bentuknya berbeda. Pendaftaran Android memerlukan identitas dan verifikasi kepemilikan level paket, sementara iOS menggunakan identifikator platform sendiri. Jika Anda menggabungkan autentikasi Google dengan lapisan autentikasi lainnya, this Capacitor social login setup with Supabase adalah contoh berguna bagaimana potongan-potongan ini seringkali berpadu.
Ini adalah panduan visual yang cukup baik jika Anda ingin membandingkan antarmuka pengguna saat 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 memberi nama aplikasi dengan tepat sangat penting.
Google menjaga kredit ini dapat diatur secara efektif dalam 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 termurah untuk menghancurkan pengaturan login Google adalah dengan menganggap ID klien satu 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 membutuhkan ID klien yang berbeda
Produk Anda mungkin adalah satu aplikasi bagi pengguna, tapi itu adalah beberapa klien OAuth bagi Google.
A Aplikasi webdan an Pembangunan Androiddan an Pembangunan 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 secara terpisah.
Penyimpanan yang terpisah itu adalah kebiasaan keamanan yang baik. Jika pengaturan kreditensial platform satu tertelan atau salah konfigurasi, platform lain tidak secara otomatis terbuka.
Berikut adalah pemisahan praktis yang harus diikuti:
- Web menggunakan ID klien web dan matching 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 aplikasi.
- Desktop atau Electron Sering menggunakan pola OAuth gaya desktop atau terinstal daripada aliran browser yang didukung rahasia.
Jenis ID Klien Google dibandingkan
| Tipe Aplikasi | Identifikasi Utama | Apakah Memberikan Rahasia Klien? | Penggunaan Utama |
|---|---|---|---|
| Web | Asal JavaScript yang Dijabarkan dan URI Redirect | Biasanya ya | Aplikasi browser dan OAuth web yang dipasang di 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 | Sering 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 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 tentang kesalahan kreditan selulerTipe 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 diakui tersembunyi di perangkat lunak sisi klien di mana pengguna dapat mengekstraknya.
Pilihan desain tersebut benar. Aplikasi seluler 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 kreditan web untuk aplikasi seluler 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 diakui.
- Aplikasi mengirimkan rahasia klien dari code yang dikemas, yang mengalahkan tujuan memiliki rahasia.
Pendekatan yang lebih baik adalah menganggap aplikasi mobile dan desktop sebagai klien umum. 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 umum.
Poin yang halus lainnya 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 dalam 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
Kebanyakan insiden OAuth 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.
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 pendaftaran klien OAuth.com.
Apa yang harus ditutup segera
Hanya lakukan beberapa hal yang benar, lakukan hal-hal ini:
- Tidak pernah kirim rahasia klien dalam aplikasi code. Paket web, biner mobile, dan paket Electron dapat diperiksa oleh pengguna.
- Pendaftaran URI redirect yang tepat. Yang cukup tidak cukup. Google memvalidasi match yang ketat untuk aliran web.
- Tetapkan asal yang ketat. Jangan mengizinkan domain yang luas hanya untuk menghindari gesekan setup.
- Terpisah kredensial platform. Jangan biarkan kemudahan memasukkan Android, iOS, dan web ke dalam satu kredit.
Detail operasional satu hal yang mudah dilupakan. Google memungkinkan tim untuk menghasilkan rahasia baru untuk ID klien yang 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 berharga untuk diterapkan juga pada 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 setiap kali.
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.
Pengaturan yang dapat menyelesaikan kebanyakan gagal adalah
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 akhirnya. 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 untuk 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 kesalahan rahasia klien. Jika implementasi Anda termasuk pekerjaan siklus token setelah sign-in, panduan revokasi yang berguna juga.
Sign-in Android gagal setelah pembuatan kredensial
Periksa kembali fingerprint SHA1 yang dihubungkan ke 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 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 miliknya 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 khusus. Capgo membantu tim mengirimkan pembaruan yang sasaran ke aplikasi code dan aset tanpa menunggu ulasan toko, yang membuatnya lebih mudah untuk memperbaiki aliran login, pengolahan panggilan balik, dan masalah autentikasi klien ketika mereka masuk ke produksi.
