Belajar Keycloak - Proteksi Brute Force & Keamanan

#Pendahuluan

Di episode 23 kalian memasang MFA di depan pintu autentikasi: TOTP, WebAuthn, dan recovery codes. Episode 24 ini melengkapi pertahanan dari sisi yang berbeda — melindungi pintu itu sendiri dari serangan brute force, lalu memperkuat area yang sering terlupakan: security headers, sesi, token, dan rutinitas audit keamanan. Kalau episode 22 membahas apa yang tercatat di log, episode ini membahas cara mencegah hal buruk terjadi sejak awal.

#Proteksi Brute Force di Realm

Brute force adalah serangan menebak kredensial dengan mencoba jutaan kombinasi password. Keycloak menyediakan mekanisme built-in bernama Brute Force Detection yang diaktifkan per realm lewat menu Realm Settings → Security Defenses → Brute Force Detection. Begitu diaktifkan, Keycloak mencatat setiap percobaan login yang gagal dan menahan autentikasi begitu jumlahnya melewati ambang.

#Cara Kerja Penghitungan Gagal

Setiap kegagalan login menaikkan penghitung untuk user tersebut, dan Keycloak juga memisahkan penghitungan berdasarkan IP asal. Dua jenis lockout yang dihasilkan:

• Temporary account lockout — terjadi begitu failureFactor tercapai; akun ditahan selama waitIncrementSeconds sebelum percobaan berikutnya diizinkan.
• Permanent lockout — jika percobaan gagal terus berlanjut, durasi penahanan naik bertahap sampai menyentuh maxFailureWaitSeconds, menciptakan efek lockout yang praktis permanen.

Pengaturan kunci yang perlu kalian kuasai:

failureFactor adalah ambang paling penting: dengan nilai 5, akun ditahan sementara setelah lima percobaan gagal. waitIncrementSeconds menentukan durasi penahanan, dan nilainya naik setiap percobaan gagal berlanjut — sampai akhirnya maxFailureWaitSeconds menciptakan lockout berkepanjangan. Kombinasi inilah yang membuat penyerang kehabisan waktu sebelum sempat menebak.

#IP-Based Blocking

Keycloak menghitung percobaan gagal per user sekaligus per IP asal. Agar penghitungan per IP akurat, Keycloak harus mengenali alamat IP klien yang sebenarnya. Dengan reverse proxy di depan, yang terlihat adalah IP proxy — kecuali header X-Forwarded-For dipakai:

kc.sh start --proxy-headers xforwarded

kc.sh start --proxy-headers xforwarded membuat Keycloak mempercayai header yang diteruskan proxy. Tanpa ini, serangan dari banyak IP dihitung seolah datang dari satu IP proxy yang sama, dan lockout per IP kehilangan maknanya.

#CAPTCHA Integration

Untuk lapisan tambahan, Keycloak punya langkah Insert CAPTCHA di flow autentikasi browser. Di menu Authentication → Flows, salin flow browser dengan tombol Copy, beri nama baru (misalnya browser captcha), lalu tambahkan eksekusi Insert CAPTCHA dan letakkan tepat setelah langkah Password. Saat pola mencurigakan terdeteksi, manusia bisa lewat dengan mengetik kode, sementara bot akan tersendat.

#Security Headers

Keycloak mengirim sejumlah security headers secara default. Kalian tetap harus paham artinya, karena reverse proxy di depan bisa menimpa atau menambahkannya:

Jika kebijakan default kurang ketat, perkuat di lapisan proxy — contoh NGINX:

Menambah security headers di NGINX

add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Catatan penting: X-XSS-Protection bukan pengganti CSP. Fokuskan upaya pada Content-Security-Policy yang benar, bukan header yang sudah banyak diabaikan browser.

#Session Security

Sesi adalah titik paling empuk: begitu sesi dibajak, penyerang menjelma menjadi user. Pertahanan berlapis:

• Session hijacking prevention — transport selalu HTTPS, cookie dengan atribut Secure agar tidak bocor lewat HTTP, dan SameSite untuk membatasi pengiriman cookie lintas situs.
• Session fixation prevention — Keycloak mengganti ID sesi saat login berhasil, sehingga penyerang tidak bisa memaksa korban memakai ID sesi yang sudah diketahuinya.
• Secure cookies — pastikan cookie Keycloak memakai HttpOnly, Secure, dan SameSite yang sesuai dengan arsitektur kalian.
• CSRF protection — alur OIDC memakai parameter state untuk membuktikan request datang dari aplikasi yang sama; jangan pernah membuangnya.

#Token Security

Token adalah identitas berjalan. Lindungi berlapis:

• Signature verification — klien wajib memverifikasi tanda tangan JWT memakai public key dari endpoint JWKS. Jangan pernah mempercayai token tanpa verifikasi.
• Token encryption — untuk pertukaran yang memuat data sensitif, gunakan JWT signed plus encrypted sehingga payload tidak terbaca pihak tengah.
• Token binding — ikat token pada karakteristik koneksi, misalnya sertifikat TLS klien, sehingga token tidak bisa dipakai dari koneksi lain.
• Token revocation — manfaatkan endpoint revoke untuk mencabut refresh token yang bocor, dan rotasi kunci realm secara berkala lewat Realm Settings → Keys.

#Security Auditing

Semua kontrol di atas butuh penjagaan rutin, bukan sekali pasang lalu lupa:

• Regular security reviews — tinjau ulang konfigurasi realm, klien, dan kebijakan token secara berkala.
• Penetration testing — uji alur login, redirect, dan endpoint admin dari sudut pandang penyerang.
• Vulnerability scanning — pantau basis data CVE untuk Keycloak, JDK, dan image container yang dipakai.
• Security patching — selalu tahu versi yang berjalan dan rancang jalur upgrade cepat (dibahas di episode 29).

Event admin dari episode 22 adalah bahan baku audit: gabungkan dengan percobaan login yang ditolak untuk melihat pola serangan lebih awal.

#Ringkasan Ancaman dan Mitigasi

#Penutup

Episode 24 mengajarkan kalian menutup celah di lapisan paling dekat dengan penyerang: Brute Force Detection dengan failureFactor, waitIncrementSeconds, dan maxFailureWaitSeconds; IP-based blocking yang bergantung pada X-Forwarded-For; CAPTCHA di flow browser; security headers; keamanan sesi dan token; serta rutinitas auditing yang menjaga semuanya tetap segar.

Inti yang harus dibawa pulang:

• Brute force bukan masalah kapasitas, tapi waktu — penahanan bertahap dengan maxFailureWaitSeconds membuat serangan tidak ekonomis.
• Akurasi IP adalah fondasi — tanpa --proxy-headers xforwarded, semua perlindungan per IP jadi buta.
• Lapisi sesi dan token — cookie aman, verifikasi signature, dan endpoint revoke adalah minimum yang wajib ada.
• Keamanan adalah rutinitas — patching dan audit berkala sama pentingnya dengan konfigurasi awal.

Di episode 25 berikutnya, kalian beralih dari melindungi pintu masuk ke mengatur apa yang boleh dilakukan user di dalam: fine-grained authorization dengan Authorization Services Keycloak — menentukan akses per resource, bukan sekadar per role.