Langsung ke konten utama

Google Client ID: Apa Itu dan Cara Membuatnya

Pelajari apa itu Google OAuth client ID, cara menemukannya di Google Cloud Console, serta cara membuat kredensial Web, Android, dan iOS. Atasi error sign-in yang umum terjadi.

Setup Google OAuth client ID di Google Cloud Console untuk aplikasi Web, Android, dan iOS

Sebuah Client ID Google OAuth adalah identifier aplikasi publik yang ditampilkan Google sebagai string yang berakhiran .apps.googleusercontent.com. Anda dapat membuat dan mengelolanya di Google Cloud Console di bawah Google Auth Platform > Clients atau API & Layanan > Kredensial. Nilai tersebut memberi tahu Google aplikasi terdaftar mana yang memulai Sign in with Google atau meminta token OAuth.

Anda mungkin ada di sini karena Google Sign-In seharusnya jadi integrasi cepat, tapi malah menatap layar kredensial dan bertanya-tanya kenapa satu tipe app memberi client secret sementara tipe lain tidak. Kebingungan ini wajar, terutama jika Anda membangun dengan Capacitor, Ionic, Electron, atau stack campuran web dan native.

Bagian yang dilewatkan sebagian besar panduan adalah hal yang merusak implementasi nyata: Google Client ID spesifik per platform, dan tipe app non-web sering kali tidak mendapatkan client secret karena memang dirancang begitu. Jika Anda membuat kredensial yang salah hanya untuk memaksakan secret ke dalam flow, Anda biasanya berakhir dengan setup OAuth yang rusak dan lebih sulit di-debug daripada seharusnya.

Table of Contents

Sebelum Google mengizinkan pembuatan OAuth client, proyek harus mendaftarkan aplikasi untuk Google Auth. Google akan meminta Anda menyelesaikannya saat membuka Google Auth Platform > Clients untuk pertama kalinya.

Langkah-langkah umum:

  1. Buka Google Cloud Console dan pilih proyek yang akan mengelola proses sign-in.
  2. Buka Platform Google Auth (atau APIs & Services > Layar persetujuan OAuth pada navigasi versi lama).
  3. Pilih Eksternal atau Internal tipe user, lalu isi nama aplikasi, email dukungan, dan kontak developer.
  4. Tambahkan scope yang akan diminta aplikasi (untuk sign-in dasar, email dan profile sudah umum digunakan).
  5. Simpan dan ikuti alur consent screen sampai aplikasi terdaftar.

Nama aplikasi di layar ini adalah yang dilihat user pada prompt izin Google. Nama ini harus sesuai dengan aplikasi yang mereka instal, bukan codename internal.

Cara membuat OAuth 2.0 client ID

Google mendokumentasikan alurnya di Kelola OAuth Client halaman bantuan. Kedua cara ini bisa digunakan:

  1. Google Auth Platform > Clients (lalu BUAT CLIENT)
  2. API & Layanan > Kredensial (lalu Buat kredensial > OAuth client ID)

Pilih atau buat project Cloud terlebih dahulu. Jangan menyebar kredensial auth di berbagai project yang tidak terkait.

Seseorang sedang mengetik di laptop yang menampilkan Google Cloud console untuk membuat kredensial OAuth 2.0 client.

Klien aplikasi web

Gunakan tipe ini untuk aplikasi browser dan untuk ID klien web banyak mobile SDK mengharapkan sebagai server audience.

  1. Klik BUAT CLIENT (atau buat) ID klien OAuth dari Credentials).
  2. Pilih Aplikasi web sebagai tipe aplikasi.
  3. Atur Asal JavaScript yang diizinkan ke setiap origin yang menjalankan UI sign-in Anda (scheme, host, dan port harus sama persis). Gunakan http://localhost:<port> untuk pengembangan lokal. Sesuai aturan Google, origin produksi wajib menggunakan HTTPS kecuali localhost.
  4. Atur URI pengalihan yang diizinkan ke setiap callback URL yang digunakan server atau SPA Anda setelah diarahkan kembali oleh Google.
  5. Klik Buat. Salin Client ID dan simpan Client secret dengan aman. Google mungkin hanya menampilkan secret ini satu kali.

Untuk aplikasi hybrid Capacitor, Web client ID sering digunakan untuk verifikasi token meskipun sign-in menggunakan native SDK. Lihat Cara Sign In dengan Google Menggunakan Capacitor untuk konfigurasi mobile lengkapnya.

Client Android (package name dan SHA-1)

Client OAuth Android menghubungkan Google Sign-In ke nama package dan SHA-1 dari sertifikat signing.

  1. Klik BUAT CLIENT lalu pilih Android.

  2. Masukkan Nama package dari aplikasi Anda (misalnya com.example.app, yang cocok applicationId di Gradle).

  3. Dapatkan sidik jari sertifikat SHA-1 untuk keystore yang menandatangani build yang sedang Anda uji:

    keytool -list -v -keystore path-to-debug-or-production-keystore -alias your-key-alias

    Untuk debug keystore default, Google mencatat passwordnya sering kali android dan path-nya biasanya ~/.android/debug.keystore.

  4. Tempel SHA-1 ke dalam formulir dan klik Buat.

  5. Salin Android Client ID. Google biasanya tidak tidak memberikan client secret untuk tipe ini.

Jika aplikasi ada di Google Play, daftarkan juga Play App Signing SHA-1 dari Play Console Integritas aplikasi. Play menandatangani ulang rilis dengan key yang berbeda dari upload keystore Anda.

client iOS (bundle ID)

  1. Klik BUAT CLIENT lalu pilih iOS.
  2. Masukkan Bundle ID dari Xcode (nilai yang sama dengan CFBundleIdentifier di Info.plist, contohnya com.example.app).
  3. Opsional, tambahkan ID App Store dan ID Tim saat diminta oleh Google.
  4. Klik Buat dan salin iOS Client ID.

Gunakan client ini dengan native iOS Google Sign-In atau dengan @capgo/capacitor-social-login saat Anda mengonfigurasi provider Apple dan Google untuk Capacitor.

Panduan ini bisa jadi referensi visual yang oke kalau Anda ingin membandingkan UI sambil mengeklik langkah-langkahnya:

Cara menemukan client ID yang sudah ada

Setelah dibuat, buka Google Auth Platform &gt; Clients atau API &amp; Layanan &gt; Kredensial. Setiap baris menampilkan OAuth 2.0 Client ID berdasarkan nama dan tipe. Buka client untuk menyalin Client ID string (xxxx.apps.googleusercontent.com). Web client juga menampilkan Client secret management di halaman detail yang sama.

Consent screen bukan sekadar hiasan. Ini adalah bagian dari trust boundary. Pengguna akan melihat nama aplikasi Anda di sana, bukan nama proyek internal Anda.

Client ID vs client secret

Kredensial Who sees it Kegunaan umum
Client ID Publik. Aman untuk disematkan di aplikasi dan frontend. Mengidentifikasi aplikasi Anda ke Google di setiap alur OAuth.
Client secret Rahasia. Hanya untuk server atau CI. Membuktikan backend Anda memiliki Web OAuth client saat pertukaran code-for-token.

Google mengklasifikasikan Aplikasi web client yang berjalan di server Anda sebagai private client yang dapat menggunakan secret. Android, iOS, dan terinstal client lain adalah public client. Google sengaja tidak menyertakan secret karena pengguna dapat mengekstrak apa pun yang disertakan dalam APK atau IPA.

Jangan membuat Web client untuk aplikasi mobile hanya untuk mendapatkan secret. Ketidaksesuaian itu menyebabkan invalid_client, DEVELOPER_ERROR, serta error token audience yang membingungkan nantinya.

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.

Diagram yang menjelaskan bahwa Google Client ID berfungsi sebagai pengenal unik dan lapisan keamanan bagi aplikasi.

Bayangkan client id Google yang diterbitkan Google sebagai username publik.

Ini memberi tahu Google, “permintaan ini datang dari aplikasi terdaftar ini.” Hal ini penting saat proses sign-in, consent, token exchange, dan alur apa pun saat 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.
key API mengidentifikasi proyek untuk panggilan API tertentu yang tidak melibatkan delegasi otorisasi pengguna.
Client secret adalah pasangan rahasia yang hanya digunakan pada flow dan tipe aplikasi yang dapat menjaga kerahasiaan dengan aman.

Banyak integrasi yang rusak bermula saat seseorang menganggap keduanya sebagai variasi dari hal yang sama. Padahal tidak.

Jika Anda butuh Masuk dengan Google atau One Tap, client ID adalah nilai yang dipakai frontend Anda untuk memulai proses autentikasi. Dokumentasi Google juga menyebutkan bahwa aplikasi harus terdaftar di proyek Cloud Console khusus sebelum kredensial dapat dibuat, dan bahwa aplikasi web memerlukan authorized JavaScript origins atau redirect URI yang dikonfigurasi dengan scheme dan hostname lengkap.

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 benar untuk menentukan apakah secret masuk ke dalam flow tersebut

Jika Anda ingin pengantar yang lebih luas tentang bagaimana identitas aplikasi dan delegated access saling terkait, panduan otorisasi aplikasi ini adalah penyegaran yang bagus. Untuk OAuth2 secara end-to-end di Capacitor, lihat OAuth2 di aplikasi Capacitor.

Konfigurasi Client ID Spesifik Platform

Cara tercepat 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 instruksi client Android Google.

Produk Anda mungkin terlihat sebagai satu aplikasi bagi pengguna, namun 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. Google mengatasinya dengan memberikan model registrasi app tersendiri untuk tiap platform.

Berikut adalah pembagian praktis yang perlu diikuti:

  • Web menggunakan web client ID serta pencocokan origin dan redirect URI yang ketat.
  • Android menggunakan Android client ID yang terhubung dengan package identity dan SHA1 fingerprint.
  • iOS menggunakan client ID iOS yang terikat pada bundle identity aplikasi.
  • Desktop atau Electron sering menggunakan pola OAuth gaya desktop atau terinstal, bukan browser flow berbasis secret.

Perbandingan tipe Google Client ID

Tipe Aplikasi Identifier Utama Menyediakan Client Secret? Use Case Utama
Web Authorized JavaScript origins dan redirect URIs Biasanya iya Aplikasi browser dan web OAuth berbasis backend
Android Identitas package plus SHA1 fingerprint Seringkali tidak Sign-in native Android
iOS Identitas app bundle Seringkali tidak Sign-in native iPhone dan iPad
Desktop Identitas aplikasi terinstal Often no Aplikasi desktop, termasuk alur native gaya Electron

Paradoks client secret untuk mobile dan desktop

Developer mobile dan desktop sering kali mengharapkan setiap OAuth client menyertakan keduanya, yaitu sebuah client ID dan client secret. Lalu mereka membuat Aplikasi Web kredensial karena itulah satu-satunya cara mereka bisa melihat secret di konsol.

Menurut panduan OAuth client Google, tipe non-web application seperti Android, iOS, dan aplikasi terinstal sengaja hanya menerima client ID tanpa client secret, karena Google tidak ingin ada secret rahasia yang tertanam di software client-side yang bisa diekstrak pengguna.

Bagi tim Capacitor, ini biasanya muncul dalam salah satu dari dua pola buruk:

  1. Aplikasi menjalankan alur berbasis browser menggunakan client web lalu mencoba berperan sebagai confidential server.
  2. Aplikasi mengirimkan client secret dari code yang di-bundle, yang justru menghilangkan fungsi dari sebuah secret.

Pendekatan yang lebih baik adalah memperlakukan aplikasi mobile dan desktop sebagai client publik. Jika backend Anda terlibat, jaga agar operasi rahasia tetap berada di backend dan batasi aplikasi native hanya pada apa yang seharusnya dilakukan oleh client publik.

Poin penting lainnya berlaku untuk sign-in Android berbasis Firebase. Dalam setup tersebut, client ID tipe aplikasi web digunakan sebagai OAuth client ID backend, sementara aplikasi Android tetap menggunakan identitas spesifik platformnya sendiri. Keduanya memiliki peran berbeda.

Jika Anda hanya perlu ingat satu aturan, ingatlah 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, mengatur redirect terlalu luas, atau menaruh secret di tempat yang tidak aman.

Panduan OAuth dari Google menganggap client secret sebagai kredensial rahasia yang harus berada di server yang Anda kontrol. Client ID adalah pengenal publik, namun Anda tetap harus mendaftarkannya dengan hati-hati. Untuk web app, Google memvalidasi client ID terhadap redirect URI yang sudah terdaftar. Jika tidak cocok persis, Google akan menolak request tersebut.

Seorang developer profesional duduk di meja sambil meninjau kredensial keamanan di dua monitor komputer di kantor.

Jika Anda hanya ingin fokus pada beberapa hal, lakukanlah ini:

  • Jangan pernah menyertakan client secret di app code. Web bundle, binary mobile, dan paket Electron dapat diperiksa oleh user.
  • Daftarkan redirect URI secara persis. Hasil yang 'mendekati' tidaklah cukup. Google memvalidasi kecocokan ketat untuk web flow.
  • Batasi origin dengan ketat. Jangan mengizinkan domain luas hanya agar proses setup lebih mudah.
  • Pisahkan kredensial per platform. Jangan biarkan kemudahan membuat Anda menyatukan Android, iOS, dan web dalam satu kredensial.

Tim yang profesional memperlakukan kredensial OAuth layaknya secret produksi lainnya. Mereka menyimpan web client secret di backend, menyuntikkannya melalui manajemen environment, dan mengaudit siapa saja yang punya akses ke console. Jika Anda sedang merapikan release pipeline, panduan tentang mengelola secrets di pipeline CI/CD ini juga layak diterapkan pada setup auth Anda.

Mengatasi error Client ID yang umum

Kebanyakan kegagalan Google OAuth disebabkan oleh beberapa kesalahan setup yang serupa. Pesan error-nya mungkin tidak selalu jelas, tapi masalah utamanya biasanya sederhana setelah Anda tahu bagian mana yang harus diperiksa.

redirect_uri_mismatch

Aplikasi Anda mengirimkan redirect URI yang tidak sesuai dengan yang terdaftar untuk web client tersebut. Periksa scheme, host, path, dan perbedaan karakter di akhirnya.

invalid_client

Ini biasanya berarti aplikasi mengirimkan client ID yang salah, secret yang salah untuk client tersebut, atau mencampur kredensial antar platform.

origin_mismatch (Alur JavaScript)

Origin halaman tidak terdaftar di bawah Asal JavaScript yang diizinkan untuk Web client.

Minimal satu client id diperlukan saat Google sign-in diaktifkan (Supabase, Firebase, dan dashboard serupa)

Toggle provider aktif tetapi ID klien web kosong atau salah tempel dari project lain. Buat OAuth clients di Google Cloud Console. Untuk Supabase, masukkan Web, Android, dan iOS client IDs sebagai daftar yang dipisahkan koma, dengan Web client ID di urutan pertama saat merilis platform tersebut. Konfigurasi native clients, lalu simpan. Untuk Supabase plus Capacitor, ikuti setup social login Capacitor dengan Supabase.

DEVELOPER_ERROR, error 10, atau sign-in berhasil di debug tapi gagal di production pada Android

OAuth client Android hilang atau nama package / SHA-1 tidak cocok dengan keystore yang menandatangani APK pengguna. Tambahkan fingerprint sertifikat Play App Signing untuk build dari store. Pastikan plugin Anda menggunakan ID klien web di mana SDK membutuhkan server client ID, seperti dijelaskan dalam dokumentasi Capgo Social Login.

Google Sign-In jalan di web tapi gagal di mobile

Periksa tipe client terlebih dahulu. Web credential tidak bisa menggantikan Android atau iOS client untuk native flows.

Layar consent terlihat salah

Verifikasi nama aplikasi dan branding pada layar OAuth consent di Google Cloud Console.

Urutan debugging praktisnya sederhana: cek tipe client dulu, lalu redirect settings, lalu platform identifiers, baru cek apakah secret tersebut memang dibutuhkan dalam flow.

FAQ

Apakah Web client ID dan Android client ID harus berada dalam proyek Google Cloud yang sama?

Ya. Untuk Google Sign-In di Android, buat Android client (package name dan SHA-1) serta Web application client dalam proyek Google Cloud yang sama. Aplikasi mengirimkan Web client ID sebagai server client ID, dan Google memverifikasi bahwa Android client tersebut berasal dari proyek yang sama. Ketidakcocokan adalah penyebab umum DEVELOPER_ERROR. Dokumentasi plugin social login Capgo menunjukkan cara setup-nya.

Apa itu Google client ID?

Ini adalah identifier OAuth 2.0 publik yang diberikan Google saat Anda membuat kredensial untuk aplikasi Anda. Biasanya terlihat seperti 123456789012-abcdefg.apps.googleusercontent.com. Google menggunakannya setiap kali aplikasi Anda memulai Sign in with Google atau menukar authorization code dengan token.

Di mana saya bisa menemukan Google client ID saya?

Di Google Cloud Console, buka Google Auth Platform &gt; Clients atau API &amp; Layanan &gt; Kredensial, lalu buka OAuth 2.0 client Anda. Bagian Client ID berisi string lengkap yang perlu disalin.

Apakah client Android dan iOS menyertakan client secret?

Biasanya tidak. Aplikasi yang terinstal adalah public OAuth client. Gunakan client secret hanya pada server yang Anda kontrol, biasanya dengan Aplikasi web Klien OAuth.

Mengapa backend saya mengatakan minimal satu client id diperlukan?

Google sign-in sudah aktif di dashboard tetapi tidak ada client ID yang tersimpan. Buat OAuth client di Google Cloud Console dan tempelkan setidaknya Web client ID ke konfigurasi provider sebelum mengaktifkan fitur ini untuk pengguna.

Apa solusi untuk DEVELOPER_ERROR di Android?

Daftarkan Android OAuth client dengan package name dan SHA-1 signing key yang sesuai pada perangkat. Jika Anda mendistribusikannya melalui Google Play, sertakan Play App Signing SHA-1. Pastikan Web client ID sesuai dengan yang diharapkan oleh auth SDK Anda.

Bisakah saya menggunakan satu client ID untuk semua platform?

Tidak. Buat OAuth client terpisah untuk Web, Android, dan iOS. Aplikasi Capacitor biasanya mengonfigurasi ketiganya meskipun pengguna hanya melihat satu produk.


Jika tim Anda merilis aplikasi Capacitor atau Electron, bug auth jarang sekali terisolasi. Masalah tersebut biasanya muncul bersamaan dengan tekanan rilis, kebutuhan rollback, dan perbaikan spesifik lingkungan. Capgo membantu tim mengirimkan update terarah ke code app dan aset tanpa menunggu review store, sehingga jauh lebih mudah untuk memperbaiki alur login, penanganan callback, dan masalah auth client-side saat lolos ke produksi.

Live updates untuk aplikasi Capacitor

Saat bug web-layer sudah live, kirim perbaikannya lewat Capgo alih-alih menunggu berhari-hari untuk persetujuan app store. Pengguna mendapat update di background, sementara perubahan native tetap mengikuti jalur review normal.

Terbaru dari Blog kami

Capgo memberikan insight terbaik yang Anda butuhkan untuk membuat aplikasi mobile yang benar-benar profesional.