SAML Adalah Fractal Desain Buruk: Kapan Harus Pindah ke OIDC

Kalau organisasi kamu masih memakai SAML untuk single sign-on, ada pertanyaan yang jarang diajukan terbuka: protokol ini masih layak dipertahankan, atau sudah waktunya dipensiunkan? Trail of Bits menerbitkan analisis tajam pada 21 September 2026 yang jawabannya cukup jelas. SAML, menurut mereka, adalah fractal desain buruk. Setiap lapisan yang dibuka menyingkap lapisan masalah berikutnya.

Kritik ini bukan sekadar keluhan estetika soal XML yang bertele-tele. Yang dibahas adalah bug class yang sudah diketahui sejak 2012, sudah dipublikasikan, sudah ada alat deteksinya, dan masih muncul di produk produksi sampai 2025. Artikel ini merangkum lima cacat desain yang diuraikan Trail of Bits, kenapa serangan terhadap SAML masih hidup, dan urutan realistis kalau organisasi memutuskan pindah ke OIDC.

Kenapa SAML Lahir dan Apa Masalahnya Sejak Awal

SAML dibuat pada 2002 oleh Security Services Technical Committee di bawah OASIS. Cara pembuatannya sudah memberi petunjuk soal hasilnya. Protokol ini dibentuk dari empat spesifikasi keamanan berbasis XML yang digabung menjadi satu: S2ML dari Netegrity, AuthXML dari Securant, X-TASS dari VeriSign, dan ITML dari Jamcracker. Komite yang menyusun protokol dengan cara menggabungkan kontribusi vendor seperti itu cenderung menghasilkan desain yang menampung semua kepentingan, bukan desain yang ramping.

Pada masanya, kebutuhan itu nyata. Internet bergerak dari era Web 1.0 ke Web 2.0, dan kampus-kampus menjadi pendorong utama. Central Authentication Service muncul di Yale pada 2002, Shibboleth IdP dirilis Internet2 pada 2003, ADFS dari Microsoft juga 2003, dan simpleSAMLphp sekitar 2007 oleh Uninett. Setelah fondasi akademik itu terbentuk, industri komersial masuk: Ping Identity (2002), OneLogin (2009), Okta (2009), lalu Duo Security (2010). Sebagian besar dari mereka berdiri di atas SAML.

Thomas Ptacek merangkum fondasi teknisnya dengan kalimat yang sulit dibantah: SAML bekerja, asalkan kamu mengasumsikan validasi XML signature itu andal. Masalahnya, validasi XML signature sangat rumit sampai sebagian besar implementasi SAML di lapangan cuma membungkus libxmlsec, basis kode C yang menurut Ptacek tidak dibaca siapa pun.

Cacat Satu: Dibangun di Atas XML

XML bukan sekadar format yang lebih verbose daripada JSON. XML punya daftar bug class sendiri yang harus ditangani oleh setiap pustaka SAML sebelum sampai ke fungsionalitas SAML itu sendiri: XXE, entity expansion alias billion laughs, pengambilan DTD yang bisa jadi SSRF, sampai injeksi XPath, XQuery, XInclude, XSLT, dan CDATA.

Perbandingan kompleksitasnya kasar tapi jujur. Di XML ada tag, elemen, atribut, komentar, namespace, pembedaan markup dan konten, skema, CDATA, DOCTYPE. Di JSON pada dasarnya hanya ada kunci, nilai, objek, dan daftar. Kompleksitas umumnya berlawanan dengan keamanan, dan itu sebabnya Trail of Bits menyebut SAML sebagai fractal desain buruk.

Cacat Dua: Canonicalization

Canonicalization atau C14N adalah proses mengubah XML yang berantakan menjadi representasi yang konsisten sebelum dihitung hash-nya. Kalau penyedia layanan dan penyedia identitas tidak menyepakati representasi yang sama, byte-nya tidak akan sejajar, tanda tangan tidak cocok, dan autentikasi gagal.

Masalahnya, menyepakati representasi itu jauh lebih sulit daripada kedengarannya. Bug canonicalization adalah pintu masuk untuk bug parser differential dan bug round-trip, dan itulah yang mendominasi serangan SAML modern. Daftar pengungkapan koordinasinya panjang dan tidak berhenti: kerentanan round-trip di pustaka standar Go pada 2020, rangkaian perbaikan implementasi XML pada 2021, penyalahgunaan quirk libxml2 untuk melewati autentikasi SAML di GitHub Enterprise pada 2025, lalu beberapa riset 2025 lain soal parser differential, SAML roulette, dan bypass tanda tangan SAML.

Yang penting dicatat: bug class-nya sudah diketahui sejak lama. Pada 2018, Kelby Ludwig menemukan bypass lewat komentar XML yang memanfaatkan perilaku canonicalization. Delapan tahun kemudian, keluarganya masih produktif.

Cacat Tiga: Enveloped Signature

Di JWT, tanda tangan terpisah dari payload JSON dan dipisahkan oleh titik. Di SAML, elemen Signature disisipkan ke dalam elemen Assertion yang sedang ditandatangani. Inilah yang disebut enveloped signature, dan konsekuensinya serius: sangat sulit mendapatkan representasi byte-for-byte yang ekuivalen secara kanonik ketika data yang kamu tandatangani justru sedang kamu ubah.

Kesulitan itu berlipat ketika formatnya XML dengan aturan canonicalization yang rumit. Inilah akar keluarga serangan XML signature wrapping atau XSW. Riset rujukannya adalah makalah 2012 berjudul On Breaking SAML: Be Whoever You Want to Be, yang menguji teori ke praktik dan menghasilkan cara otomatis untuk memeriksa serangan XSW. Meskipun sudah jadi fokus riset sejak 2012, XSW masih ada sampai sekarang.

Cacat Empat: Desain Kitchen-Sink

Ini cacat yang lebih halus tapi berdampak praktis besar. Karena dirancang di muka oleh komite, SAML memuat banyak fitur yang diantisipasi tetapi hampir tidak pernah dipakai. Kenyataannya, hampir semua implementasi SAML modern memakai bentuk data dan subset spesifikasi yang mirip satu sama lain. Autentikasi SAML yang kamu temui di lapangan kemungkinan besar menghindari 90 persen isi spesifikasi.

Artinya, kompleksitas besar dipelihara untuk fitur yang sebagian besar tidak terpakai. Ptacek bahkan menyarankan pendekatan defensif: selain semua pemeriksaan SAML standar, tolak setiap pesan yang bentuknya tidak sama dengan yang dihasilkan Okta, OneLogin, Google, atau Shibboleth. Saran itu praktis, tapi sekaligus pengakuan bahwa spesifikasinya jauh lebih luas daripada kebutuhan nyata.

Cacat Lima: Ossifikasi

SAML dirancang untuk era yang berbeda dan tidak menerima pembaruan yang diperlukan ketika lanskap berubah. Ada tiga bentuk ossifikasi yang disebutkan.

• OIDC mengasumsikan HTTP, sedangkan SAML tidak bergantung transport. Binding HTTP memang ada dan paling umum dipakai, tapi tidak wajib. Fleksibilitas itu harus didefinisikan dengan baik, diimplementasikan di suatu tempat, dan bisa mengandung bug. SAML lahir sebelum HTTP plus TLS menjadi tulang punggung komunikasi layanan web, dan tidak pernah berdamai dengan kenyataan itu.
• OIDC mengasumsikan topologi jaringan yang terhubung, SAML tidak. Alur OIDC yang paling umum, authorization code, mengasumsikan penyedia OpenID dan relying party bisa berkomunikasi langsung. SAML menyediakan artifact binding untuk komunikasi langsung, tapi jarang dipakai. Padahal, ketika kedua pihak bisa bicara langsung, tekanan pada payload respons untuk memuat semua informasi keputusan autentikasi jadi jauh berkurang.
• OIDC tumbuh organik, SAML dirancang di muka. OIDC terdiri dari puluhan spesifikasi dan RFC yang lahir untuk menyelesaikan kebutuhan spesifik. Timeline-nya menunjukkan itu: spesifikasi OpenID Connect 1.0 pada 2014, tumpukan JOSE lewat RFC 7515 sampai 7519 pada 2015, PKCE lewat RFC 7636 pada 2015, PKCE untuk aplikasi mobile dan native lewat RFC 8252 pada 2017, device authorization grant untuk perangkat IoT lewat RFC 8628 pada 2019, DPoP untuk alur MFA lewat RFC 9449 pada 2023, dan PKCE untuk SPA lewat RFC 10117 pada 2026.

Konteks sejarahnya menjelaskan banyak hal. SAML besar di era VPN dan segmentasi jaringan. Kalau penyedia identitas atau penyedia layanan berada di balik firewall korporat dan tidak bisa bicara langsung ke ujung yang lain, seluruh peluncuran berhenti dan vendor kehilangan deal. Karena itu SAML harus mengakomodasi situasi tersebut secara mulus. Model BeyondCorp dari Google dan arsitektur zero trust pada 2014 membalik asumsi itu. SAML juga tidak mengantisipasi gelombang mobile, SPA, dan IoT.

Kalau Memutuskan Pindah, Urutannya Sederhana

Kesimpulan Trail of Bits lugas: tidak ada protokol yang sempurna, tapi semua jalan menuju OIDC. Satu-satunya skenario penerapan di mana SAML punya keunggulan adalah jaringan di mana penyedia layanan dan penyedia identitas tidak bisa berkomunikasi langsung. Untuk itu pun, alur implicit OIDC dengan form post menyediakan bahan yang sama.

Untuk penyedia layanan yang ingin masuk ekosistem SSO tanpa SAML, resepnya singkat: dukung OIDC, tinggalkan SAML. Beberapa perusahaan sudah mengambil sikap itu. Fly.io menyatakan berhasil mempertahankan garis di OIDC, dan Tailscale juga. Artinya, tekanan dari sisi penyedia layanan sudah ada dan bukan sekadar teori.

Untuk organisasi yang belum bisa pindah total, urutan yang masuk akal: inventarisasi dulu semua integrasi SAML yang aktif dan mana yang benar-benar dipakai, lalu klasifikasikan berdasarkan apakah penyedia layanan dan penyedia identitas bisa berkomunikasi langsung. Integrasi yang bisa bicara langsung adalah kandidat migrasi paling murah. Sambil menunggu, perkuat sisi pertahanan dengan menolak pesan SAML yang bentuknya menyimpang dari pola umum penyedia identitas besar, dan pastikan pustaka XML yang dipakai benar-benar dipelihara.

Yang tidak boleh dilakukan adalah menganggap SAML aman karena sudah bertahan lama. Umur panjang sebuah protokol bukan bukti keamanan, kadang justru sebaliknya: cukup lama untuk semua bug class-nya ditemukan, tapi juga cukup lama untuk tetap dipakai setelah bug-nya diketahui.

Yang Perlu Diwaspadai Saat Migrasi

Migrasi dari SAML ke OIDC bukan pekerjaan sekali jalan, dan beberapa hal berikut sering menjadi sumber masalah.

• Pemetaan atribut tidak identik. Klaim di OIDC dan atribut di SAML punya nama serta struktur berbeda. Kesalahan pemetaan bisa membuat pengguna kehilangan akses ke aplikasi yang seharusnya boleh dibuka.
• Alur logout berbeda secara mendasar. SAML punya single logout berbasis XML, sedangkan OIDC memakai pendekatan yang lebih longgar. Sesi yang tetap hidup di satu aplikasi setelah pengguna keluar adalah keluhan paling umum pasca migrasi.
• Penanganan kunci berbeda. Token yang ditandatangani memerlukan kunci yang dirotasi dengan benar, dan rotasi yang salah bisa membuat seluruh pengguna gagal masuk sekaligus.
• Pengujian perlu dua arah. Uji jalur sukses dan jalur gagal, termasuk token kedaluwarsa, tanda tangan yang tidak valid, dan audience yang salah.

Pendekatan yang lebih aman adalah migrasi bertahap: jalankan OIDC berdampingan dengan SAML untuk satu aplikasi kecil dulu, ukur masalah nyatanya, baru perluas. Menyalakan kedua protokol sekaligus untuk semua aplikasi dalam satu malam akan membuat diagnosis kegagalan jauh lebih sulit, dan ketika masalah muncul, tidak ada titik acuan untuk membandingkan.

Sumber

• Trail of Bits, "SAML: A fractal of bad design", 21 September 2026: https://blog.trailofbits.com/2026/09/21/saml-a-fractal-of-bad-design/
• Makalah rujukan serangan XSW, "On Breaking SAML: Be Whoever You Want to Be" (2012), sebagaimana dikutip dalam artikel di atas.
• Kutipan Thomas Ptacek (2021 dan 2023) sebagaimana dikutip dalam artikel Trail of Bits.

Untuk konteks kerentanan pada rantai pasok perangkat lunak, ada juga catatan kasus supply chain yang bisa dibaca sebagai pelengkap: Kasus supply chain paket npm.