Belajar Keycloak - OAuth 2.0 Fundamentals

#Pendahuluan

Episode 3 membedah arsitektur Keycloak. Episode 4 ini mulai menyelam ke protokol yang paling sering kalian pakai: OAuth 2.0. Kalian akan memahami empat peran yang selalu terlibat, komponen endpoint dan token, seluruh grant type dengan kapan memakainya, serta pertimbangan keamanan yang wajib diingat. Materi ini menjadi dasar untuk episode 5 yang membedah Authorization Code flow langkah demi langkah.

#Peran dalam OAuth 2.0

OAuth 2.0 mendefinisikan empat peran yang bekerjasama:

Penting untuk memahami batasan peran ini. Resource owner hampir selalu pengguna manusia. Client bisa berupa aplikasi web, aplikasi mobile, atau bahkan service backend yang bertindak atas nama dirinya sendiri. Authorization server dalam konteks kita adalah Keycloak. Resource server adalah API yang menyimpan data yang ingin diakses.

#Komponen OAuth 2.0

OAuth 2.0 mendefinisikan beberapa komponen yang menjadi titik kontak alur:

• Authorization endpoint — tempat pengguna diautentikasi dan menyetujui (consent) akses.
• Token endpoint — tempat klien menukar kode atau kredensial menjadi token. Di Keycloak berlokasi di /realms/{realm}/protocol/openid-connect/token.
• Scopes — cakupan izin yang diminta klien, seperti openid, profile, dan email.
• Access token — kredensial sementara untuk mengakses resource.
• Refresh token — kredensial untuk memperoleh access token baru setelah kedaluwarsa.

Berikut contoh respon dari token endpoint:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJidWRpIiwiYXVkIjoicG9ydGFsLWFwcCJ9...",
  "expires_in": 300,
  "refresh_expires_in": 1800,
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJidWRpIiwiZXhwIjoyMzQ1Njc4OTB9...",
  "token_type": "Bearer"
}

Perhatikan expires_in: access token berumur pendek (300 detik dalam contoh), sementara refresh_token punya masa hidup lebih panjang. Desain ini disengaja — token yang berumur pendek meminimalkan kerusakan jika bocor.

#Grant Types: Cara Mendapatkan Token

OAuth 2.0 mendefinisikan beberapa cara (grant type) untuk mendapatkan token, masing-masing sesuai konteks:

• Authorization Code — paling aman untuk web app: kode singkat ditukar dengan token di server, password tidak pernah terlihat browser. Episode 5 membedahnya penuh.
• Implicit — mengirim token langsung di redirect URL; tidak aman dan sudah deprecated.
• Password (ROPC) — username dan password dikirim langsung ke token endpoint; hanya untuk klien tepercaya dan tidak direkomendasikan.
• Client Credentials — untuk komunikasi antar service tanpa pengguna.
• Device Code — pengguna memasukkan kode di perangkat lain yang punya browser.

#Memilih Grant Type

Empat pertimbangan yang menyempitkan pilihan:

• Apakah ada pengguna? — jika tidak, pakai Client Credentials; jika ya, pakai grant type interaktif.
• Bisakah klien menyimpan secret? — jika tidak (SPA, mobile), pakai Authorization Code dengan PKCE atau Device Code.
• Bentuk aplikasi apa? — web dengan backend memakai Authorization Code; perangkat tanpa browser memakai Device Code.
• Seberapa tepercaya klien? — ROPC hanya untuk klien tepercaya dan tetap tidak disarankan.

Aturan praktis: jika ragu, pilih Authorization Code + PKCE. Ini kombinasi paling aman untuk hampir semua kasus dengan pengguna.

#OAuth 2.0 di Keycloak

Keycloak memetakan peran OAuth 2.0 ke konfigurasi nyata:

• Authorization server — Keycloak itu sendiri, diakses lewat endpoint authorization dan token.
• Client — direpresentasikan sebagai client di admin console, dengan tipe akses public atau confidential.
• Scopes — dikelola lewat client scopes; ada scope bawaan seperti openid, profile, dan email.
• Access token — diterbitkan sebagai JWT yang bisa diinspeksi di endpoint token introspection.

Titik-titik ini akan menjadi menu yang sering kalian buka di admin console saat mengimplementasikan grant type di episode 5 dan seterusnya.

#Pertimbangan Keamanan

Empat hal keamanan yang wajib melekat pada setiap implementasi OAuth 2.0:

• State parameter — nilai acak yang dibawa saat memulai alur dan diverifikasi saat kembali; melindungi dari CSRF.
• PKCE (Proof Key for Code Exchange) — challenge kriptografi yang membuat kode yang dicuri tidak bisa dipakai pihak lain; wajib untuk SPA dan mobile, disarankan untuk semua.
• Token binding — mengikat token ke konteks tertentu, misalnya koneksi TLS, untuk menyulitkan pemindahan token.
• Token storage best practices — simpan access token di memori, refresh token di penyimpanan aman; jangan pernah di local storage yang terbuka ke JavaScript.

#Prinsip Utama

Sebuah kalimat yang merangkum semua pertimbangan di atas: perlakukan token seperti kunci fisik. Kunci tidak dibiarkan di tempat terbuka, tidak diberi ke orang yang tidak dikenal, dan diganti jika pernah hilang. State dan PKCE memastikan token hanya sampai ke tangan yang benar, sementara penyimpanan yang aman menjaga token tetap di tempatnya.

#Penutup

Episode 4 meletakkan dasar OAuth 2.0: empat peran, komponen authorization dan token endpoint, seluruh grant type, serta pertimbangan keamanan. Kalian sekarang tahu lokasi token endpoint Keycloak dan bentuk respon token yang akan sering kalian temui.

Inti yang harus dibawa pulang:

• OAuth 2.0 adalah kerangka authorisasi — siapa punya izin mengakses resource apa.
• Empat peran wajib dipahami — resource owner, client, authorization server, resource server.
• Grant type dipilih sesuai konteks — tidak ada satu grant type untuk semua kasus.
• State dan PKCE bukan opsional — keduanya adalah lini pertahanan pertama.

Di episode 5 berikutnya, kalian membedah Authorization Code flow secara mendetail — dari permintaan authorisasi, login pengguna, kode, penukaran token, hingga PKCE.