Konsep OAuth 2.0

Tombol “Masuk dengan Google” yang sering kita temui bekerja dengan cara yang berbeda dari semua mekanisme pada chapter sebelumnya: aplikasi tidak pernah melihat sandi akun Google kita sama sekali. OAuth 2.0 adalah protokol untuk mendelegasikan akses — pemilik akun memberi izin terbatas kepada satu aplikasi untuk mengakses datanya di layanan lain, tanpa berbagi kredensial. Chapter penutup Section ini membahas kerangka kerjanya secara konseptual: pihak-pihak yang terlibat, alur authorization code, pembatasan lewat scope, dan posisi kita — menjadi pengguna OAuth, atau penyedianya.

Empat Pihak yang Saling Bekerja #

Spesifikasi OAuth 2.0 menamai empat peran, dan keempatnya perlu dipahami sebelum membaca alurnya:

Authorization server dan resource server sering berada di satu perusahaan yang sama, tetapi perannya tetap dibedakan karena tugasnya berbeda: yang satu menerbitkan izin, yang lain menerima bukti izin. Pemisahan ini juga terlihat di aplikasi kita sendiri — Chapter Token dan JWT dan Middleware Autentikasi membangun kedua peran tersebut dalam satu proses Node.js.

Alur Authorization Code #

Jenis pemberian izin (grant type) yang paling umum untuk aplikasi web adalah authorization code. Seluruh alurnya berjalan seperti ini:

Permintaan izin dimulai dari browser yang diarahkan ke authorization server dengan parameter yang menjelaskan keinginan aplikasi — scheme sengaja dihilangkan agar mudah dibaca:

auth.example.com/authorize
  ?response_type=code
  &client_id=aplikasi-tugas
  &redirect_uri=aplikasi.example.com/callback
  &scope=read:kalendar
  &state=x7f3a9

Setelah Budi masuk dan menyetujui, authorization server mengarahkan browser kembali ke redirect_uri milik aplikasi sambil membawa authorization code — kode sekali pakai berumur sangat pendek. Aplikasi lalu menukarkan kode itu dari sisi server, disertai client_secret yang tidak pernah menyentuh browser:

POST auth.example.com/token
  grant_type=authorization_code
  code=kode-dari-redirect
  redirect_uri=aplikasi.example.com/callback
  client_id=aplikasi-tugas
  client_secret=YOUR_CLIENT_SECRET

200 OK
{ "access_token": "eyJhbGci...", "token_type": "Bearer",
  "expires_in": 3600, "refresh_token": "rt-9f2c..." }

Dua hal pada jawaban itu penting. access_token berumur pendek — satu jam pada contoh — dan dipakai persis seperti token JWT pada Chapter Token dan JWT: dikirim sebagai Authorization: Bearer <token> ke resource server. refresh_token disimpan aplikasi untuk meminta access token baru saat yang lama kedaluwarsa, sehingga Budi tidak perlu menyetujui ulang setiap jam.

Scope dan Prinsip Akses Minimal #

Parameter scope membatasi apa yang bisa dilakukan token. Aplikasi manajemen tugas yang hanya perlu membaca kalender meminta read:kalendar — bukan write:kalendar, bukan pula akses surel. Prinsip ini bernama least privilege: minta izin paling kecil yang masih membuat fitur berfungsi, karena setiap izin tambahan memperluas kerusakan bila token bocor.

Layar persetujuan yang ditampilkan authorization server kepada Budi menjabarkan scope dalam bahasa manusia, dan keputusan tetap di tangan Budi. Aplikasi juga sebaiknya meminta scope bertahap — saat pertama kali hanya yang inti, sisanya ketika fiturnya benar-benar dipakai — karena layar izin yang panjang mendorong pengguna menyetujui tanpa membaca.

Kita Pengguna atau Penyedia #

Posisi kita terhadap OAuth menentukan pekerjaan yang harus dikerjakan:

• Sebagai pengguna (consumer): aplikasi kita memakai layanan pihak ketiga — misalnya menawarkan “Masuk dengan Google” atau mengimpor kalender. Kita mendaftarkan client_id dan client_secret, mengikuti alur authorization code, lalu memverifikasi token yang diterima. Package komunitas mempermudah, namun semua langkah pada bagan di atas tetap terjadi.
• Sebagai penyedia (provider): API kita diakses aplikasi pihak ketiga atas nama pengguna kita. Kita membangun authorization server: layar persetujuan, penerbitan code dan token, validasi redirect_uri. Beban ini besar — itulah sebabnya banyak tim memilih tetap memakai session atau JWT sendiri untuk API internal, dan menyediakan OAuth hanya saat mitra eksternal benar-benar membutuhkan delegasi akses.

Satu catatan penutup yang sering membingungkan: OAuth 2.0 sendiri adalah kerangka authorization. Lapisan OpenID Connect (OIDC) dibangun di atasnya untuk menambahkan authentication — menerbitkan id_token berisi identitas pengguna yang bisa diverifikasi aplikasi. Saat kita memakai “Masuk dengan Google”, yang terjadi sebenarnya adalah OIDC: authorization code ditukar menjadi access token sekaligus id token.

Dengan OAuth, peta autentikasi dan otorisasi kita lengkap: sandi terhash dengan scrypt, status login dikelola session maupun token, endpoint dijaga middleware berlapis, dan akses bisa didelegasikan antar layanan. Fondasi ini menjadi bahan bagi Section Security yang membahas sisi lain dari keamanan aplikasi — dari prinsip dasar hingga celah khas web seperti XSS dan CSRF.

Spesifikasi dan panduan resmi tersedia di oauth.net/2 , termasuk halaman khusus authorization code grant type yang menjadi fokus chapter ini.