oauthauthlogin-sosialMahir3 mnt baca

Gambaran OAuth: Login dengan Google & co.

Konsep OAuth 2.0, alur authorization code, dan kenapa login dengan Google aman.

"Login dengan Google", tanpa menitipkan password

Kamu pasti sering menekan tombol "Login dengan Google" di aplikasi baru. Kamu tidak pernah mengetik password Google-mu ke aplikasi itu, tapi aplikasinya tahu siapa kamu. Keajaiban ini bernama OAuth 2.0: protokol yang memungkinkan aplikasi mengakses datamu di layanan lain ATAS IZINMU, tanpa pernah melihat password-mu.

Kenapa OAuth harus ada

Sebelum OAuth, caranya mengerikan: kamu harus memberikan username dan password email-mu ke aplikasi pihak ketiga agar bisa mengimpor kontak. Aplikasi itu bisa berbuat apa saja dengan akunmu. OAuth menyelesaikan dilema ini dengan token berbatas: aplikasi mendapat token yang hanya berlaku untuk data tertentu, selama waktu tertentu, dan bisa kamu cabut kapan pun.

Contoh 1: alur login dengan Google

  1. Kamu klik "Login dengan Google" di app.contoh.id.
  2. Browser membawamu ke accounts.google.com: "App Contoh ingin melihat email dan nama kamu. Izinkan?"
  3. Kamu setuju. Google mengembalikanmu ke aplikasi dengan authorization code sekali pakai.
  4. Server aplikasi menukar code itu dengan access token lewat request rahasia server-to-server.
  5. Dengan access token, aplikasi meminta profilmu ke Google API dan membuatkan session.

Kamu tidak pernah memberi password ke aplikasi. Google yang memverifikasi identitasmu, aplikasi hanya menerima buktinya.

Contoh 2: scope, batas izin token

Saat meminta izin, aplikasi menyebutkan scope, daftar data yang diminta:

scope=openid email profile

Artinya: "saya hanya butuh identitas dasar, email, dan nama." Aplikasi jahat yang meminta scope=... gmail.read (baca semua email) patut dicurigai kalau ia cuma aplikasi catatan. Pelajaran untukmu sebagai user: selalu baca scope sebelum menekan Izinkan. Sebagai developer: minta scope seminimal mungkin agar user percaya.

Kesalahan umum

Salah: mengira OAuth sama dengan autentikasi. OAuth adalah soal OTORISASI (izin akses), bukan membuktikan identitas. OpenID Connect adalah lapisan di atas OAuth yang menambahkan identitas. Yang benar: pakai OpenID Connect kalau butuh login, OAuth murni kalau butuh akses API pihak ketiga.

Salah: menaruh client secret di frontend. Alur kode di atas butuh secret yang hanya boleh ada di server. Yang benar: untuk SPA/mobile pakai alur PKCE yang dirancang tanpa secret.

Salah: meminta scope berlebihan. "Biar nanti kalau butuh sudah ada." Yang benar: prinsip least privilege, minta minimal, tambah nanti kalau perlu. Kepercayaan user itu mahal.

Istilah yang sering tertukar

IstilahArtinya
OAuth 2.0Protokol OTORISASI: "aplikasi boleh akses dataku"
OpenID ConnectLapisan IDENTITAS di atas OAuth: "ini buktinya siapa aku"
Access tokenKunci akses sementara ke data
Refresh tokenKunci untuk memperbarui access token
ScopeBatasan izin: data apa saja yang boleh diakses

"Login dengan Google" memakai OpenID Connect (butuh identitas). "Hubungkan akun Twitter untuk auto-post" memakai OAuth murni (butuh akses). Tertukar keduanya menyebabkan desain auth yang salah kaprah.

Catatan teknis: Token OAuth juga kedaluwarsa dan bisa di-refresh seperti JWT. Bedanya, penerbit token adalah pihak ketiga (Google, GitHub), bukan server-mu sendiri. Untuk praktik, coba GitHub OAuth: dokumentasinya paling ramah untuk pemula.

Tantangan

Petakan alur OAuth

Tanpa kode, jawab dengan diagram teks atau poin-poin:

  1. Urutkan 4 langkah authorization code flow dengan bahasamu sendiri.
  2. Di langkah mana password user dipakai? (Petunjuk: hanya satu tempat.)
  3. Apa bedanya authorization code dengan access token? Kenapa butuh dua-duanya, bukan langsung token saja?
  4. Sebuah aplikasi minta scope email + drive padahal cuma butuh menampilkan nama user. Apa yang salah?