Anda mungkin di sini karena Google Sign-In seharusnya mudah diintegrasikan, tapi malah bingung melihat layar kredensial dan bertanya-tanya mengapa satu tipe aplikasi memberikan client secret sementara yang lain tidak. Kebingungan ini wajar, terutama jika Anda membangun dengan Capacitor, Ionic, Electron, atau stack campuran web dan native.
Bagian yang sering dilewati tutorial adalah hal yang justru merusak implementasi nyata: Google Client ID bersifat spesifik per platform, dan tipe aplikasi non-web sering kali tidak mendapatkan client secret secara desain. Jika Anda membuat kredensial yang salah hanya demi memaksakan secret ke dalam alur, Anda biasanya akan berakhir dengan setup OAuth yang rusak dan lebih sulit di-debug dari yang seharusnya.
Table of Contents
- Menghubungkan App Anda ke Ekosistem Google
- Apa Itu Google Client ID
- Cara Membuat dan Melihat Client ID Anda
- Konfigurasi Client ID Spesifik Platform
- Mengamankan Kredensial Google API Anda
- Troubleshooting Error Client ID yang Umum
Menghubungkan App Anda ke Ekosistem Google
Banyak tim menghadapi masalah ini di saat yang sama. Mereka butuh Masuk dengan Google, atau ingin akses yang disetujui user ke Drive atau Calendar, dan kunci API tiba-tiba tidak lagi cukup.
Itu karena user sign-in dan delegated access berjalan melalui OAuth. Google butuh cara untuk mengidentifikasi app Anda, bukan cuma API yang dipanggil. Kredensial yang melakukannya adalah Google Client ID.
Jika Anda mengerjakan codebase cross-platform, kebingungan akan muncul dengan cepat. Anda mungkin punya frontend web, shell Android, aplikasi iOS, dan mungkin build Electron untuk desktop. Semuanya mungkin berbagi branding produk dan logika backend yang sama, tapi tidak seharusnya berbagi satu identitas OAuth yang sama.
Setup OAuth yang praktis biasanya bergantung pada beberapa pertanyaan implementasi:
- Tipe aplikasi mana yang harus Anda buat
- Apakah Anda memerlukan client secret
- Redirect URI atau origin mana yang harus cocok persis
- Cara menghubungkan flow mobile dan web tanpa mencampur kredensial
- Mengapa flow yang berhasil di browser gagal di dalam native wrapper
Aturan praktis: Jika aplikasi Anda meminta izin user atau sign-in, mulailah dengan memikirkan tipe client OAuth, bukan kunci API.
Perbedaan tersebut menghemat waktu di awal. Ini juga mencegah kesalahan umum membangun flow login mobile menggunakan kredensial web hanya karena konsol menampilkan lebih banyak field. Jika Anda mengimplementasikan ini di aplikasi Capacitor, panduan tentang OAuth2 di aplikasi Capacitor adalah pendamping yang berguna untuk alur di sisi aplikasi.
Apa Itu Google Client ID
Sebuah client ID Google OAuth 2.0 adalah pengenal publik untuk aplikasi Anda di sistem autentikasi Google. Google mendeskripsikannya sebagai username unik untuk aplikasi saat meminta access token dari endpoint autentikasi Google, dan menyebutkan bahwa ini berbeda dari key API karena digunakan dalam alur OAuth untuk memverifikasi identitas aplikasi selama pertukaran token, seperti dijelaskan dalam dokumentasi OAuth client Google Cloud.
Model mental sederhana
Bayangkan client ID Google yang diterbitkan sebagai milik aplikasi Anda username publik.
Ini memberi tahu Google, “permintaan ini datang dari aplikasi terdaftar ini.” Hal ini penting saat sign-in, consent, token exchange, dan alur apa pun di mana aplikasi Anda bertindak atas nama pengguna. Client ID dimaksudkan untuk dirujuk oleh aplikasi Anda maupun server auth Google.
Yang sering membingungkan adalah kredensial ini berdampingan dengan dua konsep lain yang tidak bisa saling menggantikan.
Client ID mengidentifikasi aplikasi dalam OAuth.
kunci API mengidentifikasi proyek untuk panggilan API tertentu yang tidak melibatkan delegasi otorisasi pengguna.
Client secret adalah pasangan rahasia yang hanya digunakan dalam alur dan tipe aplikasi yang dapat menjaga kerahasiaan dengan aman.
Banyak integrasi yang rusak bermula saat seseorang menganggap hal-hal ini sebagai variasi dari hal yang sama. Padahal tidak.
Implementasi praktis client id Google
Jika Anda butuh Masuk dengan Google atau One Tap, client ID adalah nilai yang dipakai frontend Anda untuk memulai handshake autentikasi. Dokumentasi Google juga menyebutkan bahwa aplikasi harus didaftarkan di proyek Cloud Console khusus sebelum kredensial dapat dibuat, dan aplikasi web memerlukan konfigurasi authorized JavaScript origins atau redirect URI dengan skema dan hostname lengkap.
Itulah sebabnya penyiapannya terasa lebih ketat daripada sekadar membuat key sederhana. Google tidak hanya memberikan akses, tetapi juga mengikat permintaan auth ke identitas aplikasi yang dikenal.
Bagi tim yang membangun aplikasi hybrid, model mental yang paling aman adalah ini:
- Gunakan client ID untuk mengidentifikasi aplikasi
- Gunakan consent screen untuk merepresentasikan aplikasi ke pengguna
- Gunakan tipe aplikasi yang tepat untuk menentukan apakah secret termasuk dalam flow
Jika Anda ingin pengantar yang lebih luas tentang bagaimana identitas aplikasi dan delegated access saling terkait, panduan otorisasi aplikasi ini adalah referensi yang bagus.
Cara Membuat dan Melihat Client ID Anda
Alur konsol telah berubah cukup banyak sehingga developer sering merasa salah masuk menu. Padahal sebenarnya tidak. Google saat ini menyediakan dua rute navigasi untuk kredensial ini: rute baru Google Auth Platform > Clients dan rute lama API & Layanan > Kredensial seperti yang dijelaskan dalam dokumentasi setup Google.
Mulai dari area konsol yang tepat
Buka Google Cloud Console dan pilih atau buat project yang akan mengelola konfigurasi auth. Jangan menyebar auth di banyak project secara acak. Ini akan menyulitkan proses audit dan support nantinya.
Dari sana, buka salah satu dari tempat berikut:
- Google Auth Platform > Clients
- API & Layanan > Kredensial
Jika tim Anda melihat label navigasi yang berbeda, itu hal yang wajar. Google memisahkan pengaturan identitas dari permukaan kredensial API lainnya.
Buat kredensial tanpa membatasi diri Anda
Saat Anda membuat OAuth client baru, keputusan terbesarnya adalah tipe aplikasi. Google meminta Anda memilih tipe spesifik seperti Web, Android, iOS, atau Desktop. Pilihan tersebut bukan sekadar kosmetik. Hal ini menentukan bagaimana aplikasi diidentifikasi dan konfigurasi pendukung apa yang diperlukan.
Untuk aplikasi web, Anda perlu memasukkan:
- Asal JavaScript yang diizinkan
- URI pengalihan yang diizinkan
Nilai tersebut harus tepat. Untuk kredensial web, Google memerlukan skema dan hostname lengkap, seperti https://www.example.com, bukan sekadar konsep domain yang longgar.
Untuk platform mobile, formatnya berbeda. Registrasi Android memerlukan verifikasi identitas dan kepemilikan di level package, sementara iOS memakai identifier platformnya sendiri. Jika Anda menggabungkan Google auth dengan layer auth lain, setup social login Capacitor dengan Supabase ini adalah contoh bagus tentang bagaimana bagian-bagian ini sering kali saling terhubung.
Panduan ini bisa jadi referensi visual yang cukup baik jika Anda ingin membandingkan UI sambil mengklik:
Cara menemukannya nanti
Setelah dibuat, client ID muncul di daftar kredensial proyek. Di ruang proyek yang sama, tim juga mengaktifkan API dan melihat bagaimana identitas OAuth terhubung ke consent screen. Nama aplikasi yang terdaftar adalah yang dilihat pengguna saat prompt izin muncul, itulah salah satu alasan penamaan aplikasi secara akurat itu penting.
Google membuat kredensial ini tetap mudah dikelola seiring waktu. Anda bisa kembali ke dashboard untuk menyalin client ID, meninjau pengaturan, dan jika perlu, mengelola client secret yang terkait dengan kredensial tersebut.
Layar persetujuan bukan sekadar hiasan. Itu adalah bagian dari batas kepercayaan. Pengguna akan melihat nama aplikasi Anda di sana, bukan nama proyek internal Anda.
Konfigurasi Client ID Spesifik Platform
Cara tercepat untuk merusak setup login Google adalah dengan berasumsi satu client ID bisa mencakup semua platform. Padahal tidak bisa. Untuk aplikasi multi-platform, setiap platform harus mendaftarkan OAuth 2.0 client ID yang berbeda, dan setup Android secara khusus memerlukan SHA1 fingerprint untuk verifikasi kepemilikan, seperti yang tercantum dalam referensi setup platform ini.
Mengapa satu aplikasi butuh banyak client ID
Produk Anda mungkin terlihat sebagai satu aplikasi bagi pengguna, tetapi bagi Google, itu adalah beberapa OAuth client.
Sebuah aplikasi web, sebuah Build Android, sebuah build iOS, dan sebuah aplikasi desktop tidak memiliki properti keamanan yang sama. Cara mereka membuktikan identitas berbeda, dan tidak semuanya menyimpan kredensial di lingkungan yang terpercaya. Google mengatasinya dengan memberikan model registrasi aplikasi yang berbeda untuk setiap platform.
Pemisahan tersebut merupakan praktik keamanan yang baik. Jika pengaturan kredensial satu platform terkompromi atau salah konfigurasi, platform lainnya tidak akan otomatis terekspos.
Berikut adalah pembagian praktis yang perlu diikuti:
- Web menggunakan web client ID dengan pencocokan origin dan redirect URI yang ketat.
- Android menggunakan Android client ID yang terikat pada identitas package dan SHA1 fingerprint.
- iOS menggunakan iOS client ID yang terikat pada bundle identity aplikasi.
- Desktop atau Electron sering memakai pola OAuth aplikasi terinstal atau gaya desktop, bukan alur browser berbasis secret.
Perbandingan tipe Google Client ID
| Tipe Aplikasi | Identifier Utama | Menyediakan Client Secret? | Kasus Penggunaan Utama |
|---|---|---|---|
| Web | JavaScript origin yang diizinkan dan redirect URI | Biasanya ya | Aplikasi browser dan web OAuth dengan bantuan backend |
| Android | Identitas package plus SHA1 fingerprint | Seringkali tidak | Sign-in Android Native |
| iOS | Identitas app bundle | Seringkali tidak | Sign-in iPhone dan iPad Native |
| Desktop | Identitas aplikasi terinstal | Seringkali tidak | Aplikasi desktop, termasuk flow native gaya Electron |
Paradoks client secret untuk mobile dan desktop
Inilah bagian yang sering salah di banyak tutorial.
Developer mobile dan desktop sering kali mengharapkan setiap OAuth client menyertakan keduanya client ID dan client secret. Lalu mereka membuat kredensial Aplikasi Web karena hanya dengan begitu mereka bisa melihat secret di console. Alurnya terasa lebih lengkap, jadi mereka lanjut saja. Belakangan, autentikasi malah rusak dengan cara yang membingungkan.
According to penjelasan tentang ketidakcocokan kredensial mobile ini, tipe aplikasi non-web seperti Android, iOS, dan aplikasi terinstal sering kali sengaja hanya menerima client ID tanpa client secret, karena Google tidak ingin secret konfidensial tertanam di software sisi client yang bisa diekstrak pengguna.
Pilihan desain itu sudah tepat. Aplikasi mobile atau Electron bundle bukan tempat penyimpanan secret yang aman.
Yang berhasil: Alur OAuth native atau client-side yang dirancang untuk public clients.
Yang bukan: Membuat kredensial web untuk aplikasi mobile hanya demi memaksakan secret ke dalam implementasi.
Bagi tim Capacitor, ini biasanya muncul dalam salah satu dari dua pola buruk:
- Aplikasi menjalankan alur berbasis browser menggunakan client web lalu mencoba berperilaku seperti confidential server.
- Aplikasi mengirimkan client secret dari code yang di-bundle, yang justru menghilangkan fungsi dari secret tersebut.
Pendekatan yang lebih baik adalah memperlakukan aplikasi mobile dan desktop sebagai client publik. Dalam OAuth modern, hal ini umumnya berarti menggunakan flow yang tidak bergantung pada secret yang disembunyikan di dalam client. Jika backend Anda terlibat, simpan operasi rahasia di backend dan batasi aplikasi native hanya pada apa yang seharusnya dilakukan oleh public client.
Ada poin halus lain yang penting untuk sign-in Android berbasis Firebase. Dalam setup tersebut, client ID bertipe web application digunakan sebagai OAuth client ID untuk backend server, sementara aplikasi Android tetap menggunakan identitas spesifik platformnya sendiri. Pemisahan ini sering membingungkan tim karena mereka melihat kredensial web dan kredensial mobile dalam satu project yang sama dan mengira salah satunya menggantikan yang lain. Padahal tidak. Keduanya memiliki peran berbeda.
Jika Anda hanya ingin mengingat satu aturan, gunakan ini: pilih tipe client yang sesuai dengan tempat code berjalan, bukan berdasarkan bentuk kredensial yang Anda inginkan.
Mengamankan Kredensial Google API Anda
Kebanyakan insiden OAuth bukan disebabkan oleh serangan kompleks. Tim sering membocorkan kredensial, membuat pengaturan redirect terlalu luas, atau menaruh secret di tempat yang sejak awal memang tidak aman.
Panduan OAuth dari Google menekankan bahwa client ID dan secret harus diperlakukan sebagai data privat, dan untuk web app, client ID akan divalidasi terhadap redirect URI yang sudah didaftarkan sebelumnya. Jika redirect URI tidak cocok secara ketat, Google akan menolak request tersebut. Origin binding tersebut adalah bagian dari perlindungan terhadap intersepsi token, seperti yang dijelaskan dalam panduan registrasi client OAuth.com.
Apa yang harus segera diamankan
Jika Anda hanya ingin fokus pada beberapa hal, lakukan ini:
- Jangan pernah menyertakan client secret di dalam app code. Web bundle, binary mobile, dan paket Electron dapat diinspeksi oleh pengguna.
- Daftarkan redirect URI secara spesifik. Hanya 'mendekati' saja tidak cukup. Google memvalidasi kecocokan yang ketat untuk web flow.
- Batasi origin dengan ketat. Jangan mengizinkan domain yang terlalu luas hanya demi mempermudah proses setup.
- Pisahkan kredensial antar platform. Jangan biarkan kemudahan membuat Anda menggabungkan Android, iOS, dan web ke dalam satu kredensial.
Ada satu detail operasional yang mudah terlewat. Google memungkinkan tim membuat secret baru untuk client ID yang sudah ada dan menonaktifkan yang lama. Ini sangat penting saat secret terekspos atau saat Anda memperketat proses deployment.
Apa yang sebenarnya dilakukan tim keamanan
Tim yang aman dari masalah memperlakukan kredensial OAuth layaknya secret produksi lainnya.
Mereka menyimpan web client secret di backend, menyuntikkannya via manajemen environment, dan mengaudit siapa yang punya akses console. Jika Anda sedang merapikan release pipeline, panduan tentang mengelola secret di pipeline CI/CD juga layak diterapkan pada setup auth Anda.
Mereka juga meninjau metadata, bukan sekadar key. Layar persetujuan OAuth terikat dengan identitas client yang dilihat pengguna. Jika nama aplikasi ambigu atau menyesatkan, pengguna cenderung tidak percaya pada prompt atau menyetujui aplikasi yang salah.
Keamanan bukan hanya soal menyembunyikan secret. Ini juga soal memastikan identitas app, target redirect, dan layar persetujuan selalu selaras.
Troubleshooting Error Client ID yang Umum
Kebanyakan kegagalan Google OAuth berasal dari beberapa kesalahan setup yang serupa. Pesan error-nya mungkin tidak ramah, tapi masalah utamanya biasanya sederhana setelah Anda tahu apa yang harus diperiksa.
Solusi untuk sebagian besar kegagalan
redirect_uri_mismatch
App Anda mengirimkan redirect URI yang tidak cocok persis dengan yang terdaftar untuk web client tersebut. Periksa scheme, host, path, dan perbedaan karakter di akhir. Untuk web OAuth, pencocokan eksak adalah bagian dari model keamanan.
invalid_client
Ini biasanya berarti app mengirim client ID yang salah, secret yang salah untuk client tersebut, atau mencampur kredensial antar platform. Contoh umum adalah flow Android atau iOS yang tidak sengaja menggunakan kredensial web di tempat yang salah.
invalid_request
Ini memang luas, tapi di aplikasi cross-platform, ini sering mengarah ke parameter auth yang formatnya salah atau flow yang tidak cocok dengan tipe client. Periksa apakah aplikasi mencoba menyertakan secret di tempat yang tidak seharusnya, atau apakah flow OAuth yang dipilih memang membutuhkan tipe client lain.
Google Sign-In jalan di web tapi gagal di mobile
Hal pertama yang perlu diperiksa adalah tipe client. Penyebab error paling umum bagi developer mobile adalah membuat client ID tipe web hanya untuk mendapatkan client secret, padahal seharusnya pakai tipe Android atau iOS yang sering kali memang sengaja tanpa secret, seperti dijelaskan dalam penjelasan soal mismatch client secret ini. Kalau implementasi Anda mencakup pengelolaan lifecycle token setelah sign-in, panduan revocation itu juga berguna.
Sign-in Android gagal setelah pembuatan kredensial
Cek lagi SHA1 fingerprint yang terpasang di Android client. Kalau signing identity tidak cocok dengan yang diharapkan Google, aplikasi tidak bisa membuktikan kepemilikan dengan benar.
Consent screen terlihat salah
Verifikasi nama aplikasi dan branding pada setup OAuth di console. User memberi otorisasi berdasarkan apa yang mereka lihat di sana, jadi metadata yang salah memicu masalah kepercayaan sekaligus banyak tiket support.
Urutan debugging praktisnya sederhana: cek tipe client dulu, lalu redirect settings, lalu platform identifiers, baru kemudian apakah secret memang diperlukan dalam flow tersebut.
Jika tim Anda merilis aplikasi Capacitor atau Electron, bug auth jarang sekali terisolasi. Masalah ini biasanya muncul bersamaan dengan tekanan rilis, kebutuhan rollback, dan perbaikan spesifik lingkungan. Capgo membantu tim mengirimkan update terarah ke code dan aset aplikasi tanpa menunggu review store, sehingga jauh lebih mudah untuk memperbaiki login flow, callback handling, dan masalah auth client-side saat lolos ke produksi.
