Google API Key vs Service Account vs OAuth: Panduan 2026

tl;dr: Google punya tiga cara autentikasi yang sering ketuker: API key buat akses data publik lewat skrip pribadi (paling simpel, tapi cuma nandain project buat billing—bukan identitas), Service Account buat backend/server yang akses data milik aplikasi sendiri (robot pegawai, pakai file JSON), dan OAuth 2.0 buat aplikasi yang akses data milik user (Gmail/Drive orang lain, butuh izin/consent). Salah pilih = celah keamanan atau tagihan bengkak. Artikel ini bantu kamu tentuin kapan pakai yang mana, lengkap tabel banding + pohon keputusan.

Kamu lagi bikin aplikasi atau AI agent yang nyambung ke layanan Google, terus mentok di Google Cloud Console: ada “API Key”, “OAuth Client ID”, “Service Account”—harus pilih yang mana? Salah pilih bukan cuma bikin error, tapi bisa buka celah keamanan atau bikin tagihan meledak. Kabar baiknya: aturan mainnya sebenarnya sederhana kalau kamu paham apa yang lagi diautentikasi. Kalau kamu udah pernah bikin API key di Google AI Studio, kamu udah kenalan sama salah satunya—sekarang kita bandingin ketiganya biar kamu gak salah pakai lagi.

Kenapa Google punya 3 cara autentikasi?

Pertanyaan wajar: kenapa gak satu aja biar simpel? Jawabannya karena tiga skenario ini beda banget kebutuhan keamanannya. Analogi gampangnya:

API Key = kartu member toko. Nunjukin kamu member (buat itung kuota/tagihan), tapi gak bener-bener buktiin kamu siapa. Siapa aja yang pegang kartunya bisa pakai.
Service Account = robot pegawai. Punya identitas sendiri, kerja di backend atas nama aplikasi, akses gudang data milik aplikasi itu sendiri.
OAuth 2.0 = surat kuasa dari user. Kamu minta izin ke user, user setuju, baru kamu boleh akses data milik user itu (email dia, Drive dia) selama izin masih berlaku.

Kunci membedakannya: data siapa yang mau kamu akses, dan apakah butuh persetujuan orang lain? Sisanya tinggal ngikut.

Google API Key: identifikasi project, bukan identitas

API key itu string panjang (formatnya kira-kira AIzaSy••••••••••••••••••••••ewQe—diawali AIzaSy, ditutup beberapa karakter acak) yang gunanya ngaitin request ke sebuah project buat keperluan billing dan kuota. Perhatikan: API key tidak ngidentifikasi siapa yang manggil. Dia gak tau kamu “principal” mana—makanya dia gak bisa dipakai buat cek izin akses (IAM) beneran. (Catatan: jangan pernah tampilkan API key asli kamu secara utuh di mana pun—termasuk di screenshot atau dokumentasi—karena siapa pun yang melihatnya bisa langsung memakainya.)

Cocok buat:

Akses data yang emang publik (Maps, Translate, YouTube data publik).
Skrip pribadi atau proyek kecil yang cuma manggil model AI (contohnya Gemini via AI Studio).
Prototipe cepat yang gak nyimpen data sensitif user.

Bahayanya: karena “siapa yang pegang, dia yang bisa pakai”, API key yang bocor = orang lain bisa numpang kuota kamu dan bikin tagihan kamu bengkak. Ini kenapa API key wajib di-restrict (batasi API mana yang boleh dipakai + dari domain/IP mana). API key gak dikenai biaya buat dibuat, tapi pemakaian API di baliknya bisa berbayar.

Service Account: robot backend yang akses data milik aplikasi

Service Account adalah akun khusus yang mewakili aplikasi, bukan manusia. Dia punya identitas sendiri (email format nama@project.iam.gserviceaccount.com) dan biasanya diautentikasi pakai file kunci JSON yang berisi private key.

Cocok buat:

Komunikasi server-to-server (backend kamu manggil API Google tanpa ada user yang login).
Akses data milik aplikasi itu sendiri (misal spreadsheet yang kamu share ke email service account-nya).
Otomasi backend/cron job yang jalan 24/7 tanpa interaksi manusia.
Impersonation user di Google Workspace lewat domain-wide delegation (skenario enterprise).

Yang harus hati-hati: file JSON service account itu ibarat kunci gudang—siapa yang pegang, dia punya semua akses yang dimiliki service account itu. Jangan pernah commit file ini ke GitHub. Banyak insiden kebocoran gara-gara file JSON ke-push ke repo publik. Kalau kamu pakai AI agent yang butuh baca-tulis data internal, alur ini mirip yang dibahas di panduan akses OpenClaw ke Google Drive.

OAuth 2.0: izin atas nama user

OAuth 2.0 dipakai ketika aplikasi kamu perlu akses data milik user lain—email mereka, file Drive mereka, kalender mereka. Bedanya paling fundamental: OAuth butuh persetujuan (consent) dari user. Alurnya: user diarahkan ke halaman login Google → user menyetujui izin yang diminta → aplikasi kamu dapat access token (+ refresh token buat perpanjang).

Cocok buat:

Aplikasi yang punya fitur “Login with Google”.
Aplikasi yang akses Gmail/Drive/Calendar milik user (bukan milik aplikasi kamu).
Skenario di mana kamu harus bisa buktiin “user X yang ngasih izin, bukan aplikasi yang maksa”.

OAuth adalah yang paling aman untuk data user karena user pegang kendali—mereka bisa cabut izin kapan aja. Tapi juga paling ribet setup-nya (butuh consent screen, redirect URI, penanganan token). Buat aplikasi yang jalan di banyak platform (web, Android, iOS), kamu perlu Client ID terpisah per platform.

Tabel banding: API Key vs Service Account vs OAuth 2.0

Aspek	API Key	Service Account	OAuth 2.0
Yang diautentikasi	Project (buat billing/kuota)	Aplikasi (identitas robot)	User (atas nama manusia)
Butuh consent user?	Tidak	Tidak	Ya (wajib)
Akses data siapa?	Data publik	Data milik aplikasi	Data milik user
Bentuk kredensial	String key	File JSON (private key)	Client ID + token
Tingkat keamanan	Paling lemah (siapa pegang bisa pakai)	Menengah (JSON = kunci penuh)	Paling kuat (user kendali)
Kerumitan setup	Paling gampang	Menengah	Paling ribet
Contoh nyata	Skrip panggil Gemini/Maps	Backend baca Google Sheets internal	App “Login with Google” akses Gmail user

Pohon keputusan: kapan pakai yang mana?

Jawab tiga pertanyaan ini berurutan:

Kamu mau akses data milik USER lain (email/Drive mereka)?
→ Ya: OAuth 2.0. Stop di sini, gak ada opsi lain.
Kalau tidak—kamu jalan di server/backend tanpa user login, akses data milik aplikasi sendiri?
→ Ya: Service Account.
Kalau tidak—cuma akses data publik atau panggil model AI dari skrip pribadi?
→ Ya: API Key (jangan lupa di-restrict).

Patokan singkat: data user → OAuth · data aplikasi/backend → Service Account · data publik/skrip → API Key.

Kesalahan umum yang bikin celah keamanan

Pakai API key buat data user. API key gak tau siapa user-nya, jadi mustahil buat autentikasi identitas seseorang. Ini kerjaan OAuth.
Commit file JSON service account ke GitHub. Kesalahan klasik. Bot scanner nyari file ini di repo publik dalam hitungan menit. Selalu pakai .gitignore dan environment variable.
API key tanpa restriction. Key yang gak dibatasi = tiket gratis buat siapa pun yang nemuin. Batasi per API dan per domain/IP.
Nyimpen kredensial hardcode di kode. Baik API key maupun kunci lain, jangan ditulis langsung di source code. Pakai .env atau secret manager.
Pakai OAuth buat backend cron job. OAuth butuh user consent—gak cocok buat proses otomatis tanpa manusia. Itu ranah service account.

Kalau kamu lagi mikirin apakah tetap pakai layanan API pihak ketiga atau pindah, pertimbangan keamanan kredensial ini juga masuk hitungan—kami bahas terpisah di panduan kapan berhenti pakai API AI pihak ketiga.

Pertanyaan yang Sering Ditanya

Apa perbedaan utama API key dan OAuth 2.0?

API key cuma ngaitin request ke project buat billing/kuota dan dipakai untuk data publik—dia gak ngidentifikasi user. OAuth 2.0 mengautentikasi user tertentu dengan persetujuan mereka, dan dipakai untuk akses data milik user (misal Gmail atau Drive mereka). Singkatnya: API key buat data publik/skrip, OAuth buat data user.

Apakah Google API key gratis?

Membuat API key gratis dan tidak dikenai biaya. Yang bisa berbayar adalah pemakaian API di baliknya—banyak API punya kuota gratis (free tier), tapi kalau lewat batas atau pakai API premium (misal Maps volume tinggi), kamu bakal ditagih sesuai penggunaan.

Kapan harus pakai Service Account, bukan OAuth?

Pakai Service Account kalau aplikasimu jalan di server/backend tanpa ada user yang login, dan mengakses data milik aplikasi itu sendiri (bukan data user). Contoh: cron job yang baca spreadsheet internal 24/7. OAuth dipakai kalau kamu butuh akses data milik user dengan persetujuan mereka.

Kenapa OAuth dianggap lebih aman daripada API key?

Karena OAuth mengautentikasi identitas user dan user memegang kendali—mereka bisa mencabut izin kapan saja, dan aksesnya dibatasi scope tertentu. API key sebaliknya: siapa pun yang memegang key-nya bisa memakainya tanpa verifikasi identitas, sehingga lebih rawan disalahgunakan kalau bocor.

Apakah service account dan API key bisa dipakai bersamaan?

Bisa, dan malah umum di proyek kompleks. Google bahkan mendukung “authorization key”—API key yang diikat ke service account—sehingga request diproses seolah memakai identitas service account tersebut. Tapi untuk kasus sederhana, cukup pilih satu sesuai kebutuhan.

Bagaimana cara mencegah tagihan bengkak karena kredensial bocor?

Terapkan restriction pada API key (batasi API dan domain/IP), simpan kredensial di environment variable atau secret manager (bukan hardcode/GitHub), dan pasang billing alert serta quota limit di Google Cloud Console supaya kamu langsung tahu kalau ada lonjakan pemakaian mencurigakan.

Penutup

Tiga metode ini bukan soal mana yang “paling bagus”—tapi mana yang pas buat skenario kamu. Salah satu penyebab paling sering aplikasi rentan atau tagihan bengkak adalah pakai metode yang salah: API key buat sesuatu yang harusnya OAuth, atau JSON service account yang bocor ke repo publik. Mulai dari pertanyaan “data siapa yang mau diakses?”, sisanya ngikut.

Kalau kamu baru mulai dan cuma butuh nyambungin model AI ke agent atau skrip, mulai dari yang paling simpel dulu: bikin API key gratis di Google AI Studio. Buat yang mau serius bangun AI agent yang aman dari nol—termasuk cara ngatur kredensial yang bener—kamu bisa belajar terstruktur lewat workshop KomuniTech (2 jam, langsung praktik bikin Karyawan AI sendiri).

Referensi

Disclaimer: Detail antarmuka Google Cloud Console dan kebijakan kuota bisa berubah sewaktu-waktu. Selalu cek dokumentasi resmi Google untuk informasi terkini.

Artikel telah diupdate pada 05/08/2026 untuk memastikan artikel tetap sesuai kondisi terkini.