Belajar Kerberos - Alternatif Autentikasi Modern

#Pendahuluan

Di episode 27, kalian membawa Kerberos ke cloud dan berhadapan dengan container, API, dan ekosistem yang semakin heterogen. Di tengah ekosistem itu muncul pertanyaan yang sering diajukan: apakah Kerberos masih relevan, atau sudah tergantikan oleh OAuth2 dan OIDC? Episode 28 ini menjawab dengan jujur: bukan soal mengganti, melainkan soal memilih alat yang tepat dan membuat semuanya bekerja sama. Kerberos, OAuth2, OIDC, dan SAML punya kekuatan di wilayah yang berbeda.

#Peta Alternatif Modern

Sebelum membandingkan, pastikan kalian paham empat nama yang sering dicampuradukkan:

Kerberos — protokol autentikasi jaringan berbasis ticket, dirancang untuk enterprise network.
OAuth2 — framework otorisasi untuk memberi akses ke API dengan token akses.
OIDC (OpenID Connect) — lapisan autentikasi di atas OAuth2 yang menambahkan ID token.
SAML — format assertion XML untuk SSO lintas organisasi, umum di web enterprise.

#Kerberos vs OAuth2/OIDC

Perbandingan dasarnya:

Dimensi	Kerberos	OAuth2 / OIDC
Fungsi utama	Autentikasi plus otorisasi via ticket	Otorisasi via token; OIDC menambah autentikasi
Format kredensial	Ticket biner terenkripsi	Access token / ID token (JWT)
Klien utama	Workstation, server, aplikasi jaringan	Aplikasi web, mobile, API
Mekanisme	KDC, AS, TGS, ticket dan session key	Authorization server, redirect, token endpoint
Dukungan mobile dan browser	Sulit	Dirancang untuk itu
Masa hidup di enterprise	Puluhan tahun, masih dominan	Semakin umum diadopsi

Kerberos dirancang untuk dunia di mana klien dan server berada di jaringan yang sama dan bisa berkomunikasi langsung dengan KDC. OAuth2 dirancang untuk dunia internet, di mana klien seperti browser dan perangkat mobile tidak berbagi kredensial rahasia dengan server.

#Web vs Jaringan Enterprise

Pilihan protokol bergantung pada konteks:

Web dan mobile — browser tidak bisa menyimpan cache ticket seperti workstation. OIDC dengan alur redirect dan token di browser adalah pendekatan yang alami.
Enterprise network — mesin yang bergabung ke domain, layanan jaringan seperti filesystem dan print, serta aplikasi legacy justru paling cocok dengan Kerberos.

Mencoba memaksa OIDC ke seluruh jaringan enterprise sama salahnya dengan memaksa Kerberos ke aplikasi web publik. Keduanya dibangun untuk medan yang berbeda.

#Mobile dan API

Dua medan yang jelas-jelas milik OAuth2:

Mobile — aplikasi tidak bisa diandalkan untuk menyimpan rahasia; alur OAuth2 dengan PKCE dirancang untuk situasi ini.
API — akses lintas layanan dinyatakan sebagai token akses dengan scope, bisa dicabut per klien, dan bisa dilewatkan antar-service tanpa kembali ke KDC setiap saat.

Kerberos tetap bisa melayani API internal yang berada di jaringan yang sama, tetapi untuk API publik lintas jaringan, token akses jauh lebih praktis.

#Kerberos + SAML: Federasi

SAML adalah jembatan untuk federasi: dua organisasi (atau realm dan cloud) tidak berbagi KDC, tetapi berbagi kepercayaan melalui Identity Provider (IdP). Skenario umum: aplikasi di satu organisasi menerima login dari pengguna organisasi lain. SAML memungkinkan pengguna melakukan SSO di IdP asal mereka, lalu mengirim assertion ke Service Provider (SP).

#Assertion SAML

Assertion SAML membawa informasi tentang siapa penggunanya, kapan autentikasi terjadi, dan atribut tambahan. Assertion ditandatangani oleh IdP, sehingga SP bisa memercayainya tanpa berbagi rahasia per pengguna.

Bentuk umum assertion SAML

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Subject>budi@example.com</saml:Subject>
    <saml:Conditions NotOnOrAfter="2026-08-03T12:00:00Z"/>
    <saml:AuthnStatement AuthnInstant="2026-08-03T09:00:00Z"/>
</saml:Assertion>

Federasi SAML dan Kerberos saling melengkapi: Kerberos menangani autentikasi di dalam jaringan, SAML membawa identitas itu ke organisasi atau penyedia layanan lain.

#Hybrid: Kerberos untuk Internal, OAuth untuk Eksternal

Organisasi modern memakai keduanya sekaligus. Prinsip pemisahannya sederhana:

Internal — layanan di dalam perimeter memakai Kerberos; kecepatan, integrasi direktori, dan dukungan legacy menjadi alasannya.
Eksternal — aplikasi yang melayani publik memakai OAuth2/OIDC; alur web dan mobile berjalan mulus.

Kunci agar keduanya koheren adalah memetakan identitas: principal Kerberos dan akun OIDC harus menunjuk ke entitas direktori yang sama, sehingga audit dan otorisasi tetap memakai satu sumber kebenaran.

#Federation Gateway

Federation gateway duduk di tengah: ia menerima kredensial dalam satu protokol dan meneruskannya ke protokol lain. Misalnya, aplikasi internal yang bicara Kerberos dihadirkan ke klien eksternal lewat gateway yang menangani OIDC di depan dan Kerberos di belakang.

Ilustrasi konfigurasi federation gateway

routes:
  - path: /svc/internal
    authn: kerberos
    upstream: kdc.cluster.local
  - path: /svc/public
    authn: oidc
    issuer: https://idp.example.com
    client_id: public-gateway

Important

Gateway tidak menggantikan keamanan protokol itu sendiri. Ia hanya menjembatani, dan kredensial yang berpindah tangan tetap harus dikelola dengan aturan yang sama ketatnya. Perluas audit logging di gateway — karena di sanalah dua dunia yang berbeda bertemu.

#Single Sign-On Lintas Protokol

Dengan gateway dan pemetaan identitas yang benar, pengguna menikmati SSO yang melintasi protokol: login sekali di IdP, lalu dapat mengakses aplikasi Kerberos di belakang dan API OAuth2 di depan tanpa login ulang. Hal yang perlu diingat — SSO lintas protokol menambah kompleksitas audit dan troubleshooting; kalian harus tahu di lapisan mana sebuah permintaan gagal. Membedah alurnya dengan KRB5_TRACE di sisi Kerberos akan sangat membantu saat debugging.

#Strategi Migrasi

Beralih dari autentikasi lama ke modern tidak harus menyakitkan. Empat langkah yang sering dipakai:

Inventaris — katalog aplikasi: mana yang bicara Kerberos, mana yang sudah siap OIDC.
Jembatani — aplikasi lama dibiarkan memakai Kerberos, aplikasi baru memakai OIDC.
Federasi — hubungkan realm dengan IdP lewat trust dan gateway.
Menggantikan — aplikasi legacy yang sudah diganti dapat dimatikan bertahap.

#Coexistence Patterns

Pola koeksistensi yang paling praktis: Kerberos untuk jaringan internal dan aplikasi legacy; OAuth2/OIDC untuk API, mobile, dan web publik; SAML untuk federasi lintas organisasi. Tidak ada yang benar-benar mati — masing-masing mengisi celahnya sendiri.

#Penutup

Episode 28 meletakkan Kerberos dalam peta autentikasi modern. Bukan usang: Kerberos tetap pilihan terbaik untuk enterprise network; OAuth2/OIDC unggul di web, mobile, dan API; SAML menjadi bahasa federasi antar-organisasi. Dengan federation gateway dan pemetaan identitas yang baik, semuanya bisa hidup berdampingan dan berbagi SSO.

Inti yang harus dibawa pulang:

Pilih protokol berdasar medan tempur — web dan API milik OAuth2/OIDC, jaringan enterprise milik Kerberos.
SAML adalah jembatan federasi, bukan pengganti KDC.
Hybrid bukan kekacauan — selama identitas dipetakan ke satu sumber kebenaran.
Migrasi dilakukan bertahap, dengan koeksistensi, bukan big-bang.

Di episode 29 berikutnya, kita mengalihkan fokus dari teknis ke tata kelola: compliance dan audit — bagaimana memastikan Kerberos di produksi kalian memenuhi tuntutan SOC 2, HIPAA, PCI-DSS, dan GDPR, serta bagaimana membangun audit logging dan access review yang benar.